Mail Archives: djgpp/1998/08/05/09:00:56
> > case), I would like to know if gdb can be instructed to stop if the
> > contents of a particular address change,
>
> You need to set a data breakpoint, which will fire when a certain address
> is overwritten. GDB has a `watch' command which does just that.
> Unfortunately, I have never been able to get it to work (did anybody?).
I just did. I used
(gdb) watch *0x6d17c
where 0x6d17c is the address I want to watch. I works but with
unpredictable results. *Sometimes* the program stops at the point at
which the malloc pointer to next block is overwritten, reporting that
this happens in the last loop in process_coff (I am very far from the
machine I work, so I can send you detailed line numbers later). This is
likely since the loop references the potential rogue array f_lnno.
*Sometimes* though, setting a watch point mysteriously prevents the
program from crashing and the fsdb screen comes on.
However, outside the debugger fsdb always crashes and reports exactly the
same register content which is actually malloc's internal pointer
byteshifted once.
I am currently studying process_coff to see if there is something there,
but this seems unlikely since no one has reported similar behaviour. Even
I get this crash only when I run fsdb after exiting emacs.
> The ``data-write breakpoint'' feature of FSDB *does* work. So you might
> try using it to set such a breakpoint at the offending address.
The problem is that if I can get fsdb to run, the debugged fsdb runs too.
Fortunately, if fsdb crashes from the command line, it crashes (reports
SIGSEGV) under gdb too. It is predictable and repeatable.
- Raw text -