Re: hints on debugging memory corruption...

[Joern Rennecke <joern dot rennecke at embecosm dot com>]

Quoting Basile Starynkevitch <basile@starynkevitch.net>:

> Hello All
>
> (Sorry for such a basic question; very probably there are some GDB tricks
> that I ignore).
>
> 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.

One way is to do bit of stepping or inserting breakpoints in interesting
places and see when the address gets mapped.

If this is to tedious, and the memory corruption is in the heap, and
will manifest itself also after a bit of perturbation, you can use a  
breakpoint
at main (or if the corruption happens earlier, in a constructor or init)
and call free and the result of malloc for a large memory area.
For some OSes you might also need to malloc several medium-sized blocks
and free them to actually get stuff mapped.
run to see where the corruption strikes now, then do a fresh start with the
same allocation pattern and set your watchpoint.

For other allocators, you can hack the code a bit to make the first allocated
chunk huge enough to contain the corrupted area.