Re: updatedb files portable?

[James Youngman]

On Tue, Dec 06, 2005 at 11:51:18AM -0600, Peter Fales wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0x00011a98 in visit_old_format (procdata=0xeffffa30, context=0x0)
>     at locate.c:492
> 492             *s++ = procdata->bigram1[procdata->c];
> (gdb) p s
> $1 = 0xfe038419 <Address 0xfe038419 out of bounds>
> (gdb) bt
> #0  0x00011a98 in visit_old_format (procdata=0xeffffa30, context=0x0)
>     at locate.c:492

I think the problem may be that the offsets used at the start of each
entry in the database are written with putw().  It looks to me like
putw() and getw() use native byte ordering and thus produce and expect
different results on SPARC versus Intel.  

This means that procdata->count is being set to an unexpected value at
line 479 of locate.c.  This value is then added to 's' leading to a
segmentation fault.  What worries me more is the number of cases where
by some fluke an erroneous result was produced but nobody noticed.  If
the thinking above is correct, this warrants a documentation
improvement to explicitly discourage use of the already-deprecated old
database format in heterogeneous environments.

It's probably possible to include a bounds check there in locate.c to
ensure that the result of getw() is sensible considering the length of
the previous line.  In fact, it may be possible to modify locate.c to
figure out if the system which generated the database had the same or
the opposite endianness (if a bit in the top byte of the offset of the
second entry is set, it's cross-endian).  This will not help other
'locate' implementations, though.

However, I am not sure that this would solve your whole problem and in
any case I would be unable to test such code.

Another alternative would be to lobotomize code.c to have it always
use a zero offset.  This would increase the size of the produced
database but work around the endianness issue.  However, this requires
a code change that would also need to be tested on your system to
verify that it solved your problem.

So I think the upshot is that the best thing for you to do would be to
use the 'new' database format.  Is that practical for you, or wold you
prefer to make a code modification?

Regards,
James.