Geoffrey <esoteric@3times25.net> 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
