Geoffrey <esoteric@xxxxxxxxxxxx> writes: > (gdb) bt > #0 0x0814acc9 in FileAccess (file=168481968) at fd.c:717 > #1 0x0814b2e7 in FileRead (file=168481968, buffer=0xbff816ce "", amount=2) > at fd.c:972 > #2 0x00203ecc in ?? () > #3 0x0a0ad4b0 in ?? () > #4 0xbff816ce in ?? () > #5 0x00000002 in ?? () > #6 0x00000001 in ?? () > #7 0x0a04fdc0 in ?? () > #8 0xbff83110 in ?? () > #9 0x00000001 in ?? () > #10 0x00000002 in ?? () > #11 0xbff83110 in ?? () > #12 0x00000000 in ?? () > I'm assuming that the portion of the backtrace from frame 2-12 is likely > produced from the pcmiler binaries as we do not have source and they > don't contain debugging symbols. Actually, on looking closer, most of those return addresses are obviously silly: control was certainly never passed from addresses 0, 1, or 2, and I suspect a bit of disassembling with gdb would show that the others aren't immediately after call instructions either. So it looks like gdb got confused about which words in the stack are return addresses --- which lends a bit more credibility to the idea about a stack clobber, but still offers no direct help for debugging. What I'd be inclined to look for first is local-variable buffers that might not be big enough for the values that get written into them. Perhaps the reason the failure occurred now was something as prosaic as the new installation having longer path names. In any case you need to be taking a very hard look at your glue functions, since those are the weakest link in the chain as far as the extent of portability testing they've gotten goes (assuming that pcmiler is a reasonably well-tested library). regards, tom lane
