Date: Sun, 10 Oct 1999 13:00:20 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Michael Abbott aka frEk <20014670 AT snetch DOT cpg DOT com DOT au> cc: djgpp AT delorie DOT com Subject: Re: Debugger Issues In-Reply-To: <37FD6A44.69364B8E@snetch.cpg.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Fri, 8 Oct 1999, Michael Abbott aka frEk wrote: > > > to trace the bug... Both of them run the program beautifully > > > without any hiccoughs... I presume this means that both of them turn of > > > Real-memory protection so that they don't freeze when people try to > > > watch / inspect variables that point to absolutely nothing... > > > > No, this isn't true. The debuggers don't turn off any memory > > protection. If you try to inspect an invalid address, GDB should print > > something like this: > > > >
> > Oh, okay... Rhide seems to show you the memory, even if it's protected... That's probably because the version of RHIDE you are using is based on an old version of the DJGPP debug support routines. The protection which should be at work here was introduced only lately; the ported GDB 4.18 uses it. > > I suggest to read section 12.2 of the DJGPP FAQ list. It explains how to > > understand the crash message better, and includes a procedure with which > > you could find out what variable gets garbled and causes the crash. Once > > you know that, I suggest putting a data breakpoint (a.k.a. watchpoint) at > > that variable and run your program again. When some code accesses the > > variable, the debugger will kick in and show you the offending code. (If > > you never see it accessed, you will know it is uninitialized.) > > Okay thanx... Btw, I suggest to do this with GDB, not with RHIDE, because GDB 4.18 has much improved support for watchpoints, whereas public releases of RHIDE did not yet catch up with some of these improvements (AFAIK).