Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
DeBugging
Edit
PageHistory
Diff
Info
LikePages
You are viewing an old revision of this page.
View the current version
.
You might also be interested in the CommonProgrammingBugs page. Debugging under Linux is done mostly by using gdb(1). If you want to debug a program: # Compile it with debugging support. This is done by adding the -g option to the gcc(1) command line. If you are using make(1), you can export CFLAGS=-g, you should also set -Wall too, but only because it's a good idea in general. An example: gcc -g -Wall foo.c -o foo # Load your program in gdb: "gdb ./''programname''" # type "run" at the prompt to run the program. # when the program crashes you should be able to type "bt full" to get a full backtrace of what the program was doing at the time. useful gdb(1) commands: ;bt full: give a complete backtrace of a program. If a program crashes __this__ is what the programmer will want from you. ;print: This lets you print out various expressions, eg: "print node" "print *node" "print node->key" "print node->next->key" etc. ;break: This lets you set breakpoints, eg: "break main" ;run: run a program up until a break point. ;step: step over a function call ;next: step into a function call ;frame: change which frame you are working on. eg: "frame 1" will change the scope to frame 1. !Other useful debugging tricks and traps: strace(1) lets you see what a program is doing in a corse kind of way, if you think strace(1) is too quiet, perhaps ltrace(1) is for you. for the bsdites amongst us, I believe these are called struss(1) and sotrace(1). The command for this is: strace ''programname'' if the program is already running: strace ''pid'' will also work. If your program hangs, you can press Alt-\ to send it a SIGQUIT and force it to dump core. You can also force them to dump core with the command: kill -QUIT ''programpid'' To create core files you have to remove the ulimit(1) on them. This can be done with the command: ulimit -c unlimited Note, this is for the shell (and all it's children) only. gdb(1) can also do postmortem analysis on core files like so: gdb ./''program'' ./''corefile'' If you run gdb(1) on your program and it displays the names of the functions but doesn't display their types (eg: what arguments they have or line number information) you probably didn't compile them with -g ddd(1) appears to be a reasonable [GUI] interface to gdb(1) for those that are afraid of CommandLine's. use assert(3) everywhere. It's much nicer at finding your bugs closer to where the bug actually hides.
10 pages link to
DeBugging
:
VirtualMachine
SIGQUIT
ProcessNotes
UserSubmittedNotes
CommonProgrammingBugs
GDB
MALLOC_CHECK_
AdvancedDebuggingHints
CoreDump
WritingBugReports