Geoffrey <esoteric@xxxxxxxxxxxx> 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
