Re: backend reset of database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Geoffrey <esoteric(at)3times25(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Terry Lee Tucker <terry(at)leetuckert(dot)net>, John Allgood <john(at)turbocorp(dot)com>, "j(dot) >> \"J(dot) D(dot) Pearson\"" <jpearson(at)turbocorp(dot)com>
Subject: Re: backend reset of database
Date: 2007-04-10 01:33:50
Message-ID: 16122.1176168830@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Geoffrey <esoteric(at)3times25(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Nolan 2007-04-10 02:05:55 Re: Seg fault in pg_dump?
Previous Message Robert Treat 2007-04-10 01:23:17 Re: Is there a shortage of postgresql skilled ops people