Thread: memory bug debugging

Hello hackers,

I'm fiddling around with the backend and have created a memory bug. I
guess I'm overriding a palloced chunk, but can't figure out where.

The backend's report is:

WARNING:  problem in alloc set MessageContext: req size > alloc size for
chunk 0x8383ca8 in block 0x83834a0

Investigating a little I have found out that chunk size is 8, but
requested size is: 1912602626  (more than 1GB???). This certainly
doesn't make sense.

What tools or debugging options exist to find memory leaks / overrides?
I've read the utils/mmgr/README, which leads me to the conclusion that I
cannot use valgrind or similar tools.

It would be very helpful to know what chunk it is, or better: where it
got allocated.

Thank you for your help

Markus

On Tue, Oct 04, 2005 at 01:11:41PM +0200, Markus Schiltknecht wrote:
> Hello hackers,
>
> I'm fiddling around with the backend and have created a memory bug. I
> guess I'm overriding a palloced chunk, but can't figure out where.

There are some defines (MEMORY_CONTEXT_CHECKING and
CLOBBER_FREED_MEMORY) which can help find leaks. Valgrind works too,
with a bit of attention. I was going to add some directives to allow
Valgrind to handle PostgreSQL's memory allocator, but have got there
yet.

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Tue, Oct 04, 2005 at 01:11:41PM +0200, Markus Schiltknecht wrote:
>> I'm fiddling around with the backend and have created a memory bug. I
>> guess I'm overriding a palloced chunk, but can't figure out where.

> There are some defines (MEMORY_CONTEXT_CHECKING and
> CLOBBER_FREED_MEMORY) which can help find leaks.

Those are on by default if you built with --enable-cassert (which you
should surely always do when testing new backend code).

Best idea that comes to mind is:

(1) make sure you have a reproducible scenario in which the clobber
always happens at the same physical location.  (This shouldn't be too
hard if you start a fresh backend for each trial.)

(2) run it under gdb and set a hardware watchpoint at that location.

You'll get some false matches from touches in the aset.c code, but
hopefully not too many.  The first breakpoint outside aset.c is your
problem.
        regards, tom lane