Geoffrey <esoteric@3times25.net> writes:
> Tom Lane wrote:
>> The trace is *really* suspicious given what you say here. I'm inclined
>> to think that what is really happening is that something is jumping to
>> never-never land (via a clobbered function pointer or overwriting a
>> return address on the stack) and it just happens to end up in FileRead.
>> Unfortunately that guess doesn't provide much help for debugging it :-(
> I just find it hard to believe that an address is getting clobbered or
> some such thing and we just happen to fall into the very beginning of a
> function.
Well, this trace doesn't prove any such thing. If it was a wild jump,
we can surmise that it landed someplace in the first few instructions of
FileRead (before the call to FileAccess), but there's no proof here that
it landed on-the-nose at the first instruction.
> I would also have expected that all the parms to the FileRead call would
> have been garbage, yet that does not seem to be the case:
> #1 0x0814b2e7 in FileRead (file=168481968, buffer=0xbff816ce "", amount=2)
That's actually one of the things I find suspicious: AFAICS all the
calls to FileRead in the backend (and there aren't many) use a constant
BLCKSZ value for "amount". So I doubt the 2 is an intentionally passed
parameter, it's more likely whatever happened to be in the relevant word
of the stack.
regards, tom lane
