DJGPP FAQ -- What is that gibberish printed when my program crashes?

www.delorie.com/djgpp/v2faq/faq075.html

search

9.2 What is that gibberish printed when my program crashes?

Q: My program dies with a cryptic message like "Segmentation violation" or "Unsupported DOS request" 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. 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 your-program-name

Symify then walks through the crash traceback by reading back 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 yourprog

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 core.dmp yourprog

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 be invalid.

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

webmaster donations bookstore	delorie software privacy
Copyright ⌐ 1998 by Eli Zaretskii	Updated Sep 1998

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)