Re: shall we have a TRACE_MEMORY mode - Mailing list pgsql-hackers

From Greg Stark
Subject Re: shall we have a TRACE_MEMORY mode
Date
Msg-id 87r71j533r.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: shall we have a TRACE_MEMORY mode  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Another thing to consider is that the proximate location of the palloc
> is frequently *not* very useful.  For instance, if your memory is
> getting eaten by lists, all the palloc traces will point at
> new_tail_cell().  Not much help.  I don't know what to do about that
> ... any ideas?

Well the traditional thing to do is store a backtrace a la Dmalloc, one of the
better debugging malloc libraries out there. It has mostly been superceded by
Purify/Valgrind type tools but it still has a place for handling memory leaks.

It's unfortunate that's impossible to use Dmalloc with Postgres. It would
probably be nigh impossible to merge in Dmalloc code into Postgres's allocator
given the different models. But perhaps it would be possible to steal specific
pieces of it like the backtrace grabbing code.


-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sync_file_range()
Next
From: Greg Stark
Date:
Subject: Re: Generic Monitoring Framework Proposal