From:	"John M. Aldrich" <fighteer AT cs DOT com>
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
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

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 <fighteer AT cs DOT com>  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------

- Raw text -