Re: any suggestions to detect memory corruption

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: any suggestions to detect memory corruption
Дата
Msg-id CA+TgmoajsAKmtCXvDWaaF9vHYStLPVYVPc7Lur-UocuXfkbVjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: any suggestions to detect memory corruption  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: any suggestions to detect memory corruption  (Alex <zhihui.fan1213@gmail.com>)
Список pgsql-hackers
On Wed, May 8, 2019 at 10:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alex <zhihui.fan1213@gmail.com> writes:
> > I can get the following log randomly and I am not which commit caused it.
>
> > 2019-05-08 21:37:46.692 CST [60110] WARNING:  problem in alloc set index
> > info: req size > alloc size for chunk 0x2a33a78 in block 0x2a33a18
>
> I've had success in finding memory stomp causes fairly quickly by setting
> a hardware watchpoint in gdb on the affected location.  Then you just let
> it run to see when the value changes, and check whether that's a "legit"
> or "not legit" modification point.
>
> The hard part of that, of course, is to know in advance where the affected
> location is.  You may be able to make things sufficiently repeatable by
> doing the problem query in a fresh session each time.

valgrind might also be a possibility, although that has a lot of overhead.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: vacuumdb and new VACUUM options
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance