Mail Archives: djgpp/1999/10/08/03:31:21
Heya
> 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?
No, I only saw a single line. Generally if there is a crash in my main code,
I get several lines and can trace it back nicely but when it crashes inside
an Allegro function it gives me one line...
Unless there is some other option I should be using :)
> 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.
Will do tomorrow (at work at the moment :)
> What do you mean by ``debugging frame''?
By debugging frame I mean framework... I read somewhere that, whoever
invented Rhide (I forget the name) basically used GDB and converted it to run
within the IDE...
> > 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...
> 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.
Okay... Thanx :) I'll have a look and see what's unitialised.
> 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...
> Of course, once you post the crash message, it could reveal some other
> possible cause(s) for the problem...
Will do...
- Michael
- Raw text -