Differences between version 13 and predecessor to the previous major change of DeBugging.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 13 | Last edited on Thursday, May 6, 2004 1:29:18 am | by StuartYeates | Revert |
| Older page: | version 5 | Last edited on Sunday, September 7, 2003 10:43:46 am | by DanielLawson | Revert |
@@ -1,5 +1,18 @@
-You might also be interested in the CommonProgrammingBugs page.
+You might also be interested in the CommonProgrammingBugs page. Beware of [HeisenBug]s.
+
+----
+!Contents
+
+* GDB
+* strace
+* signals
+* Core files
+* Debugging running processes
+* Other tools/commands
+
+----
+!! [GDB]
Debugging under Linux is done mostly by using gdb(1).
If you want to debug a program:
@@ -7,39 +20,79 @@
# 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:
+!!
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"
+;break: This lets you set breakpoints at functions or lines in the source code
, eg: "break main" or "break sourcefile.cpp:55
"
;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:
+!
!Other useful debugging tricks and traps:
+!strace
+strace(1) lets you see what a program is doing in a coarse
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''
+ strace -p
''pid''
will also work.
+!signals
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:
+!Core files
+
To allow crashing programs to
create [CoreDump]s
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.
+Note, this is for the shell (and all its
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
+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
.
+! modifying
a running process
+You can use
gdb to attach to a currently running process
. For example, to change where its stderr is going:
-use assert
(3
) everywhere. It's much nicer at finding your bugs closer to where the bug actually hides.
+ $ gdb <executable> <process_id>
+
(gdb
) call close(2)
+ $1 =
+ (gdb) call open("/tmp/prog-debug", 0101)
+ $2 = 2
+ (gdb) cont
+Note that the octal 0101 stands for O_CREAT|O_WRONLY, since gdb will complain about no debugging symbols for resolving those words otherwise. Check with your /usr/include files... the c library with debian testing at least has these definitions in /usr/include/bits/fcntl.h. (0100 + 01).
+
+!ddd
+ddd(1) appears to be a reasonable [GUI] interface to gdb(1) for those that are afraid of [CommandLine]s.
+
+!assert
+use assert(3) everywhere in your source code. It's much nicer at finding your bugs closer to where the bug actually hides.
+
+!Electric Fence
Make use of electricfence (libefence) for tracking memory allocation errors. In debian this can be enabled on the fly by setting an LD_PRELOAD variable, like so:
LD_PRELOAD=libefence.so.0.0 your-buggy-programme
+
+! threads
+Note: When using gdb(1) to debug a threaded program, gdb(1) catches two signals ([SIGPWR] & [SIGXCPU]) which are used internally by pthreads on Linux. Use
+ (gdb) handle SIGPWR pass nostop noprint
+ (gdb) handle SIGXCPU pass nostop noprint
+to stop gdb halting on receiving these signals.
+
+!!Other useful commands
+* catchsegv - prints out the backtrace of function calls for a program receiving a [SIGSEGV]. - don't forget to compile with __-g__ if you want file names and line numbers to be accessible.
+* c++filt(1) - reverses the C++ symbol name-mangling that gcc(1) does, so if the program uses c++ then you can read the function names.
+
+Other neat tools for diagnosing memory errors are:
+* [Valgrind]
+* electric fence
+* [MMGR] (works well with C++)
+* [mcheck] (part of libc6-dev)
+* [MALLOC_CHECK_] environment variable
+* [LD_DEBUG] environment variable
+* [DMALLOC|http://www.dmalloc.com]
+* printf(3)
+* GarbageCollection
+* AddToMe: any other neat tools you know of?
