Re: G++: GC-related ICE in CVS version

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> > My guess is that this is not a gc bug, but that a field of some tree
> > or rtx is corrupted. It would be interesting to know who the caller of
> > this function was, and at what point the value 0x60 was written into
> > that field.
> 
> The former can be determined, but the latter can't (not with my
> current tool set, anyway).

I'm curious: Why can't you set a watch point on that address in gdb? I
find that watch points in gdb work quite well, at least on x86 (where
it uses hardware support - it is a pain on Sparc Solaris, where it
does not). The trick is to use the following sequence:

1. Let it run without watchpoint, and wait for it to crash.
2. Determine the address of the location that is wrong. Normally, you'll
   have to align this to an integer boundary to make the watchpoint work.
   Suppose the address is 0x4010034.
3. Set a breakpoint on main, run the program again.
4. When it starts, type
   watch *(int*)0x4010034
5. If that succeeds, just continue, and it'll break whenever the memory
   location changes
6. If it fails, it'll probably tell you that it can't set a watchpoint
   because there is no memory at that location (yet - because
   sbreak/mmap) was not called. This is tricky to solve; I'd recommend
   setting a breakpoint on, say, start_function, and try to set the
   watch point every time when it breaks. That typically allows to set
   the watchpoint before the memory location is corrupted; if not, you
   need to try more frequently.

Regards,
Martin