This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

hints on debugging memory corruption...


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.

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.

Any hints are welcome!

Cheers

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]