From: "John M. Aldrich" Newsgroups: comp.os.msdos.djgpp Subject: Re: debugging.. Date: Fri, 08 May 1998 23:36:50 -0400 Organization: Two pounds of chaos and a pinch of salt. Lines: 61 Message-ID: <3553CF52.6486@cs.com> References: <3553C35C DOT 707A117E AT geocities DOT com> NNTP-Posting-Host: ppp121.cs.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Dan Chak wrote: > > When my program crashes, I get a screen like below. I've heard that > there's some way to figure out what line caused the crash using this > output. Can someone explain to me how this is done, please? This is explained in detail in the DJGPP Frequently Asked Questions list (v2/faq210b.zip from SimTel or online at http://www.delorie.com/djgpp/v2faq/), in Chapter 12: Debugging. Basically, the stack traceback (which you didn't attach, but that's ok) tells you: - The nature of the error that caused the crash (SIGXXXX, followed by a message) - The memory location at which the crash occurred (EIP) - The contents of the CPU registers at the moment of the crash (eax, ebx, ...) - The contents of the runtime stack at the moment of the crash (Stack frame traceback) All of this information is useful in debugging a crash, but you need to use tools to interpret it. The easiest way is to run the 'symify' program, like so: "symify myprog.exe". If you've compiled your program with debugging information ('-g' switch), you'll see a list of functions, line numbers, and source files for each frame in the stack. The topmost one is where the crash occurred, so look at that line in your program for possible errors. If the crash took place in a library function, go back frames until you get to a function that's in your own code. Tools like gdb (the GNU debugger) can assist with finding crashes in much more detail. I suggest you read the documentation and the FAQ for more information. Common causes of SIGSEGV-type crashes: - Dereferencing an uninitialized or NULL pointer, or passing such pointers to library functions. - Overflowing the runtime stack. - Overwriting a function's stack frame. - Incorrect memory allocation (e.g., assuming sizeof(int)==2), or not checking for malloc()'s return value. - Unlocked interrupt code that gets swapped to disk. If you can't figure out a problem on your own, we can often help here on the list if you post the symified traceback (capture with a command like "symify -o crash.txt myprog.exe") and the code in your program immediately around the crash point. hth! -- John M. Aldrich, aka Fighteer I UIN# 7406319 -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s+:- a-->? C++>$ U@>++$ p>+ L>++ E>++ W++ N++ o+>++ K? w(---) O- M-- V? PS+ PE Y+ PGP- t+(-) 5- X- R+(++) tv+() b+++ DI++ D++ G>++ e(*)>++++ h!() !r !y+() ------END GEEK CODE BLOCK------