Tom Lane wrote:
> 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.
So you're saying that the debugger will simply point to that function if
the address it 'jumps to' is somewhere in address space of this
function? I don't know the intricacies of the debugger to understand
how all that works. My expectation is that a random address is unlikely
to make any sense to the debugger.
>> 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.
Thanks, that makes sense. Now I've just got to figure out how it's
'getting there' to start with. :)
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
