Date: Thu, 7 Oct 1999 13:14:57 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Michael Abbott aka frEk <20014670 AT snetch DOT cpg DOT com DOT au>
cc: DJGPP Mailing List <djgpp AT delorie DOT com>
Subject: Re: Debugger Issues
In-Reply-To: <37FC3744.31BF3262@snetch.cpg.com.au>
Message-ID: <Pine.SUN.3.91.991007130031.22543A-100000@is>
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 Thu, 7 Oct 1999, Michael Abbott aka frEk wrote:

> After initialising, it bombs out with a "General Protection Fault". I
> ran SYMIFY to trace the error and found it was in one of the Allegro
> functions. Unfortunately this function is called from many different
> places in my program, so I needed to trace through it to find which
> function in my program is causing the problem...

The stack traceback printed when the program crashes should print several 
lines of addresses, and SYMIFY should add source file information to 
those lines.  These specify the *precise* sequence of function calls that 
led to the final call to the Allegro function which crashed.  Given that 
info, you shouldn't need to wonder what function called that Allegro 
function, the traceback should spell it for you.

Did you get this traceback?  Or did you only see a single line?

Btw, usually, when asking questions about crashes, it is better to post
the precise crash message, including the registers' dump and the 
SYMIFY'ed traceback, that you see on your system.  There's lots of 
important information in the crash message, which makes it much easier to 
guess what could go wrong with your program.  So please post it.

> I ran it under both RHIDE and GDB (they use the same debugging frame,
> right?)

What do you mean by ``debugging frame''?

> 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>

I don't remember what does FSDB do, but I think it should say something 
similar.

Bugs which go away when you run under a debugger are usually a sign of 
using uninitialized variables.  Since the debugged program is loaded in a 
different portion of memory, it sees differnt junk, and thus doesn't 
crash.

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.)

Of course, once you post the crash message, it could reveal some other 
possible cause(s) for the problem...

Btw, make sure you use the latest versions of the debuggers.  For GDB, 
use the ported GDB 4.18.  Previous versions had some drawbacks in some 
important features, one oif them is watchpoints.