Bug#876840: staden-io-lib FTBFS on non-i386 32bit: FAIL: java

[Adrian Bunk]

Source: staden-io-lib
Version: 1.14.9-2
Severity: serious

https://buildd.debian.org/status/package.php?p=staden-io-lib&suite=sid

...
FAIL: java
==========

=== testing ./data/aux#aux_java.cram ===
root=aux#aux_java
../progs/scramble -r ./data/aux.fa ./data/aux#aux_java.cram test.out/aux#aux_java.scramble.sam
fseeko() on reference file: Invalid argument
Unable to fetch reference #0 1..20
Failure to decode slice
Failed to decode sequence
FAIL java.test (exit status: 1)

============================================================================
Testsuite summary for io_lib 1.14.9
============================================================================
# TOTAL: 10
# PASS: 9
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
============================================================================
Makefile:706: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1

[Andreas Tille]

control: forwarded -1 James Bonfield <***@sanger.ac.uk>
control: tags -1 upstream

Hi James,

there is another issue reported to the Debian packaged io_lib
which you can read here:

https://bugs.debian.org/876840

Below is a hint what might have caused the issue.

Kind regards

Andreas.

Hi Andreas,

I need to admit I have no idea why
fseeko() on reference file: Invalid argument
is happening on some architectures.

According to the manpage of fseek(), which is identical to fseeko()
ERRORS
[...]
EINVAL The whence argument to fseek() was not SEEK_SET,
SEEK_END, or SEEK_CUR. Or: the resulting file offset would
be negative.
I suspect that something is calling fseeko() with a negative offset.
I'd recommend doing an strace on the specific test binary that
fails on a porterbox (e.g. armhf) + on amd64 for comparison and
then look for the offending fseeko() call. That might help isolate
the issue.
Regards,
Christian

[Andreas Tille]

Hi James,

I uploaded staden-io-lib now with your patch which solved the other bug.

Debugging the code for this test case shows it is doing fseeko with
offset 8 (on a working machine), SEEK_SET. Strace shows this as an
lseek SEEK_SET to offset 0 and a read of 8 for some reason, but it
amounts to the same thing.
I'll try and find a qemu / virtual machine of one of the affected
architectures to test on.
My money is on something odd to do with large file support (it's a
total minefield) and changing of types. Eg bad prototypes leading to
32-bit to 64-bit type changes yielding a daft interpretation of offset
and/or whence.
#ifdef HAVE_CONFIG_H
#include "io_lib_config.h"
#endif
Does adding that fix the fseeko call to start working again?

Unfortunately not - see here the build logs:

https://buildd.debian.org/status/package.php?p=staden-io-lib

Thanks for your quick response in any case

Andreas.

[Andreas Tille]

Hi,

this is a kind ping since as I wrote below the issue seems not be solved.

I'm not sure I can easily debug this as it only fails on systems I
have no access to; it's like trying to debug your grandmother's
windows desktop over the phone...
I'm still convinced it's something to do with large file support not
working correctly, likely with off_t being the wrong size. Especially
given the 64-bit mips build works while the 32-bit one does not. I
assume everything else about these architectures are the same.
We don't have any 32-bit build systems any more though.

Post by Adrian Bunk

Does adding that fix the fseeko call to start working again?

https://buildd.debian.org/status/package.php?p=staden-io-lib

James
--

I'm just forwarding this to debian-arm and debian-mips. I see no other
chance to deal with this bug rather than removing these architectures
from the architectures field.

Do you have any better suggestion?

Kind regards

Andreas.

[James Cowgill]

Hi,

Post by Andreas Tille

this is a kind ping since as I wrote below the issue seems not be solved.

I'm not sure I can easily debug this as it only fails on systems I
have no access to; it's like trying to debug your grandmother's
windows desktop over the phone...
I'm still convinced it's something to do with large file support not
working correctly, likely with off_t being the wrong size. Especially
given the 64-bit mips build works while the 32-bit one does not. I
assume everything else about these architectures are the same.
We don't have any 32-bit build systems any more though.

Post by Adrian Bunk

Does adding that fix the fseeko call to start working again?

https://buildd.debian.org/status/package.php?p=staden-io-lib

James
--

I'm just forwarding this to debian-arm and debian-mips. I see no other
chance to deal with this bug rather than removing these architectures
from the architectures field.
Do you have any better suggestion?

The bug is here:
https://sources.debian.org/src/staden-io-lib/1.14.9-3/io_lib/bgzip.c/#L47

Unlike most packages (although there are quite a few that do this),
staden-io-lib defines _FILE_OFFSET_BITS in a config header instead of
passing it as a -D argument to the compiler. Since this flag affects the
behavior of standard headers, you *must* include this header before any
others.

In the bgzip.c file above, stdio.h is included before the
io_lib_config.h header. This causes bgzip.c to have a different opinion
of what sizeof(off_t) compared to other files, so all external calls to
bzi_seek invoke undefined behavior.

To fix, move the "#ifdef HAVE_CONFIG_H...#endif" block above all the
other includes in that file.

Thanks,
James

[James Bonfield]

I'm unsure why I didn't get notification of James Cowgill's email, but
yes that was indeed the problem.

The bug was real of course, thanks for spotting and reporting it, but
the fix I made in September did indeed have the #include at the start:

https://github.com/jkbonfield/io_lib/commit/b0fa4620e7b7d9fc05dd5cd001f4dce9606d2776

I'm not sure quite what happened here. Was this fixed inside debian
using a manual patch, rather than pulling the fix from upstream?

Anyway, problem resolved.

Regards,

James
--
James Bonfield (***@sanger.ac.uk) | Hora aderat briligi. Nunc et Slythia Tova
| Plurima gyrabant gymbolitare vabo;
A Staden Package developer: | Et Borogovorum mimzebant undique formae,
https://sf.net/projects/staden/ | Momiferique omnes exgrabure Rathi.