Re: any suggestions to detect memory corruption - Mailing list pgsql-hackers

From Robert Haas
Subject Re: any suggestions to detect memory corruption
Date
Msg-id CA+TgmoajsAKmtCXvDWaaF9vHYStLPVYVPc7Lur-UocuXfkbVjw@mail.gmail.com
Whole thread Raw
In response to Re: any suggestions to detect memory corruption  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: any suggestions to detect memory corruption  (Alex <zhihui.fan1213@gmail.com>)
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: vacuumdb and new VACUUM options
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance