Re: backend reset of database - Mailing list pgsql-general

From Tom Lane
Subject Re: backend reset of database
Date
Msg-id 16122.1176168830@sss.pgh.pa.us
Whole thread Raw
In response to Re: backend reset of database  (Geoffrey <esoteric@3times25.net>)
List pgsql-general
Geoffrey <esoteric@3times25.net> writes:
> Tom Lane wrote:
>> 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.

It is a bit surprising that it didn't jump to a nonexistent address and
die immediately, but if you're on a little-endian machine then maybe
this isn't quite as improbable as it looks.  A stack clobber that writes
just a few more bytes than the intended buffer can hold might overwrite
just the first couple bytes of a return address, which are the LSBs on a
little-endian machine, leading to a return address somewhere within 64K
of where it should have been, which most likely is within the code area
rather than off in an unmapped range.  The fact that the code area is
only a small part of the address space doesn't change the odds if that's
what happened.

            regards, tom lane

pgsql-general by date:

Previous
From: Robert Treat
Date:
Subject: Re: Is there a shortage of postgresql skilled ops people
Next
From: "Michael Nolan"
Date:
Subject: Re: Seg fault in pg_dump?