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. _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
