From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Markus Schiltknecht <markus(at)bluegap(dot)ch>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: memory bug debugging |
Date: | 2005-10-04 14:17:27 |
Message-ID: | 7881.1128435447@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-10-04 14:17:33 | Re: \d on database with a lot of tables is slow |
Previous Message | Tom Lane | 2005-10-04 14:06:24 | Re: [PERFORM] A Better External Sort? |