Re: backend reset of database

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: backend reset of database
Дата
Msg-id 16122.1176168830@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: backend reset of database  (Geoffrey <esoteric@3times25.net>)
Список 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 по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: Is there a shortage of postgresql skilled ops people
Следующее
От: "Michael Nolan"
Дата:
Сообщение: Re: Seg fault in pg_dump?