Message-ID: <37FD6A44.69364B8E@snetch.cpg.com.au> Date: Fri, 08 Oct 1999 13:51:32 +1000 From: Michael Abbott aka frEk <20014670 AT snetch DOT cpg DOT com DOT au> Organization: Student of Computer Power Institute X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: Debugger Issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com 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: > >
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