89
« on: December 22, 2006, 12:31:26 pm »
When you're looking to debug something, learning how to use gdb (or any debugger) can be very helpful. A quick tutorial:
Before you start, you must make sure you configured Precursors (and preferably other libs, like CrystalSpace and CEL) with --enable-debug. If you didn't pass that switch to configure before compiling, do a jam distclean, re-run configure, passing it the --enable-debug switch, and run jam again. Yes, it takes a while, but it's necessary to get the debugging information inserted into the code.
After compiling everything with debugging enabled, we want to load the program (precursors, in this case) into the gdb debugger. To start gdb from the command-line, simply execute
gdb precursors
This will load the precursors program into gdb. Now, simply enter the command run at the gdb prompt. Wait for it to crash (providing it input if necessary); when it does, gdb will stop and re-display the gdb prompt.
A backtrace shows the stack trace of function calls leading up to the crash. This is often very useful, and by default should be posted / pastebinned with any bug report or help request. The backtrace command is simply bt.
Other gdb commands, like setting breakpoints and printing variable values can also be very helpful. Use the help command to learn more, or ask questions here or in chat.
An alternative is to use an IDE that has support for gdb built-in. I use Eclipse CDT for most of my RaptorNL and Precursors work (when I am actually working on the projects), and it lets me do things like see variable values by simply mousing over the variable name. Setting breakpoints and such are also easier when doing it graphically. What IDE do you use? I might be able to help you configure it to work with gdb, if it doesn't already.
Trust me, even though I still use couts and printfs for debugging, the debugger is often a much better and less trial-and-error starting point. Learn to use it, and you'll love it forever.