> On Tue, Sep 26, 2017 at 10:38:12PM +0200, Christian Seiler wrote:
> > 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.
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.
I see bgzip.c doesn't have the standard boilerplate header setup of:
#ifdef HAVE_CONFIG_H
#include "io_lib_config.h"
#endif
Does adding that fix the fseeko call to start working again?
James
--
James Bonfield (j...@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.
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
