Differences between version 21 and predecessor to the previous major change of DeBugging.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 21 | Last edited on Monday, September 12, 2005 8:50:22 am | by JohnMcPherson | Revert |
| Older page: | version 19 | Last edited on Friday, September 10, 2004 12:03:03 pm | by PerryLorier | Revert |
@@ -1,15 +1,23 @@
-You might also be interested in the CommonProgrammingBugs page. Beware of [HeisenBug]s.
+You might also be interested in the CommonProgrammingBugs page. Beware of [HeisenBug]s. If you aren't a programmer, you can help by WritingBugReports
.
----
!Contents
+* gcc compile-time options
* GDB
* strace
* signals
* Core files
* Debugging running processes
* Other tools/commands
+
+----
+!! [GCC] Compile Options
+* have -g in your CFLAGS (for [C]) or CXXFLAGS (for [C++]) environment variable so that debugging symbols are stored in your binary objects.
+* Compile with -Wall to get all 'standard' compiler warnings.
+* Compile with -Wshadow to get a warning when you declare a variable with the same name as one in an outer scope.
+* If you are using the GNU C library (eg linux systems), you can #include <mcheck.h> to get some extra debugging for malloc(3) - see the [mcheck] page
----
!! [GDB]
@@ -30,48 +38,58 @@
;step: step to the next command, or into a function call (ie go to the instructions within that function).
;next: step to the next command, or over a function call (ie treat the call as a single command)
;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
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). [Darwin] ([MacOSX]) has ptrace and ktrace (and kdump to read the created file).
The command for this is:
+<verbatim>
strace ''programname''
+</verbatim>
if the program is already running:
+<verbatim>
strace -p ''pid''
+</verbatim>
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:
+<verbatim>
kill -QUIT ''programpid''
+</verbatim>
!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:
+<verbatim>
ulimit -c unlimited
+</verbatim>
Note, this is for the shell (and all its children) only.
By default core files are placed in the working directory (often the same directory the executable is in). This may not be ideal for you if the executable is on a read only file system. To change this behaviour you can use the following command.
-
+</verbatim>
echo /var/cores/core.%e.%p >/proc/sys/kernel/core_pattern
-
+</verbatim>
%e is replaced by the executable name and %p is replaced by the pid of the process. For more possible replacements see fs/exec.c in your nearest kernel source.
gdb(1) can also do postmortem analysis on core files like so:
+<verbatim>
gdb ./''program'' ./''corefile''
-
+</verbatim>
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".
! modifying a running process
You can use gdb to attach to a currently running process. For example, to change where its stderr is going:
-
+<verbatim>
$ gdb <executable> <process_id>
(gdb) call close(2)
$1 = 0
(gdb) call open("/tmp/prog-debug", 0101)
$2 = 2
(gdb) cont
-
+</verbatim>
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).
!Graphical Debuggers
ddd(1) appears to be a reasonable [GUI] interface to gdb(1) for those that are afraid of [CommandLine]s.
@@ -87,10 +105,12 @@
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
+<verbatim>
(gdb) handle SIGPWR pass nostop noprint
(gdb) handle SIGXCPU pass nostop noprint
+</verbatim>
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.
