Date: Wed, 5 Aug 1998 13:16:47 +0000 ( ) From: "Gurunandan R. Bhat" To: Eli Zaretskii Cc: djgpp AT delorie DOT com Subject: Re: fsdb crashes post emacs In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > 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.