Mail Archives: djgpp/1999/10/07/10:05:43
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.
- Raw text -