Re: any suggestions to detect memory corruption

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alex <zhihui(dot)fan1213(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: any suggestions to detect memory corruption
Date: 2019-05-08 17:21:13
Message-ID: CA+TgmoajsAKmtCXvDWaaF9vHYStLPVYVPc7Lur-UocuXfkbVjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 8, 2019 at 10:34 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex <zhihui(dot)fan1213(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-08 18:28:13 Re: [HACKERS] Detrimental performance impact of ringbuffers on performance
Previous Message Fujii Masao 2019-05-08 17:18:48 Re: vacuumdb and new VACUUM options