Differences between version 17 and predecessor to the previous major change of DeBugging.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 17 | Last edited on Friday, June 25, 2004 1:13:58 pm | by JohnMcPherson | Revert |
| Older page: | version 13 | Last edited on Thursday, May 6, 2004 1:29:18 am | by StuartYeates | Revert |
@@ -23,17 +23,20 @@
!!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 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
+;break: This lets you set breakpoints at functions or lines in the source code, eg: "break main" or "break sourcefile.cpp:55". This can be abbreviated as just "b".
+;run: run a program up until it encounters
a break point or completes.
+;cont: start running from the current command until the next break point or the end
.
+;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).
The command for this is:
+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:
strace ''programname''
if the program is already running:
strace -p ''pid''
will also work.
@@ -45,8 +48,14 @@
!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 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.
+
+ echo /var/cores/core.%e.%p >/proc/sys/kernel/core_pattern
+
+%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:
gdb ./''program'' ./''corefile''
@@ -63,10 +72,12 @@
(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
+!Graphical Debuggers
ddd(1) appears to be a reasonable [GUI] interface to gdb(1) for those that are afraid of [CommandLine]s.
+
+[Insight] is another.
!assert
use assert(3) everywhere in your source code. It's much nicer at finding your bugs closer to where the bug actually hides.
