[an error occurred while processing this directive]
Node:Crash traceback,
Next:File data corrupted,
Previous:malloc crash,
Up:Running
Q: My program dies with a cryptic message like "SIGSEGV" or
"Page Fault" or "General Protection Fault" and prints some
funny-looking numbers. Can't I get some decent human-readable traceback
information, so I could pinpoint where in the program did the problem
happen?
A: Those "funny-looking numbers" are the traceback. They
describe the sequence of function calls which led to the fatal error by
giving you the addresses where each function was called. You can have
these addresses translated to source line numbers by using the
SYMIFY
program. SYMIFY
is included in the
basic DJGPP development environment distribution, and
should be in your bin/
subdirectory. To symify the
traceback, make sure that your program was compiled with the -g
switch, linked without the -s
switch and not
stripped of its debugging symbols by running the strip
utility. Now invoke your program and do whatever it takes to make it
crash. Then, with the traceback still on the screen, type this from the
DOS command line:
symify program-name
(Note: program-name should include the .exe
suffix.)
SYMIFY
then walks through the crash traceback by reading it
from video memory, and matches the hex addresses to the source files and
line numbers of the program. It then writes back the list of source
files and line numbers right next to their hex addresses. Now you can
start debugging. More info about this is available in how to analyze crash dumps.
One problem with this translation is that it relies on info generated by GCC that maps the instruction addresses to source line numbers. This usually works okay, but one notable exception is when you use inline assembly. In this case, GCC only records the last line of the inline assembly block, which might be way off if the block is large.
You can ask SYMIFY
to put the stack trace into a file (so you can
consult it later, e.g., from your editor while fixing the bug), by giving
it an output file, like this:
symify -o problem.dmp program-name
You can also save the raw stack trace (without source info) to a disk file
and submit it to SYMIFY
later, like this:
symify -i problem.dmp program-name
This comes in handy when your program grabs the screen (e.g., for some
graphics) and the stack trace can't be seen. You can then redirect the stack trace to a file, e.g., with the REDIR
program which comes with DJGPP.
But what if you didn't compile your program with -g
, and you
aren't sure how to recreate the problem which crashed it, after you
recompile? Well, you can submit the stack dump after you recompile
your program. Just press that PrintScreen key or otherwise save the stack
trace, then submit it to SYMIFY
from a file as described above,
after you've recompiled the program. Be sure to give gcc all the
compilation switches (sans -s
) that you gave it when you originally
compiled your program (in addition to -g
), including the
optimization switches, or else the addresses shown in the stack trace
might point to wrong places.
If all you have from the crash is the program counter, the eight-digit
hex number after "eip=", you can still find out the corresponding
source line using GDB. Assuming that the EIP value is NNNNNNNN
,
type this at the GDB prompt:
list *0xNNNNNNNN