Mail Archives: djgpp/1999/10/10/15:00:16
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:
> >
> > <Address 0xNNNNNNNN is out of bounds>
>
> 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).
- Raw text -