Differences between version 21 and previous revision of DeBugging.
Other diffs: Previous Major 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 20 | Last edited on Tuesday, September 21, 2004 2:48:05 pm | by JohnMcPherson | Revert |
@@ -1,5 +1,5 @@
-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
@@ -44,43 +44,52 @@
!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.
@@ -96,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.
