This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: hints on debugging memory corruption...
- From: Ian Lance Taylor <iant at google dot com>
- To: Basile Starynkevitch <basile at starynkevitch dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 04 Feb 2011 08:18:05 -0800
- Subject: Re: hints on debugging memory corruption...
- References: <20110204154203.GA19472@ours.starynkevitch.net>
Basile Starynkevitch <basile@starynkevitch.net> writes:
> In my MELT branch I have now some corrputed memory (maybe because I am
> inserting a pass at the wrong place in the pass tree). At some point, I call
> bb_debug, and it crashes because the field bb_next contains 0x101 (which is
> not a valid adress).
>
> So I need to understand who is writing the 0x101 in that field.
>
> How do you folks debug such issues.
>
> An obvious strategy is to use the hardware watchpoint feature of GDB.
> However, one cannot nicely put a watchpoint on an address which is not
> mmap-ed yet.
>
> But I don't know how to ask gdb to be notified when a given adress is
> becoming valid in the address space. Putting a breakpoint on mmap is really
> not funny.
I usually put a breakpoint on the allocation routine and make it
conditional on returning the address I am interested in. Once that
address is returned, I can put a hardware breakpoint on the field value
being changed. This approach is only moderately successful in practice.
Ian