This is an old revision of the document!
Table of Contents
Debugging
Colorgcc
- install colorgcc
- make sure ~/bin path is in your $PATH variable before /usr/bin
- place symlinks in ~/bin/:
cc -> /usr/bin/colorgcc g++ -> /usr/bin/colorgcc gcc -> /usr/bin/colorgcc
- create a ~/.colorgccrc file, and define inside the location of the real cc, gcc, g++ binaries:
/usr/bin/cc, gcc, g++
Segmentation Faults
The crash occurs where the error is
It's the simpler case, which fortunately happens (null pointers, etc).
The solution is to use a debugger like GDB to watch variable contents (see gdb_summary).
You have several possibilities to get into the program where the segfault occurred :
- run the program with gdb
- configure your shell to create a core dump when the program crashes (
ulimit -c unlimited
for bash and zsh,limit coredumpsize unlimited
for tcsh; thefile
command tells you which program created the core dump), and inspect the core dump with gdb. - catch the sigsegv signal and freeze the program, then attach the debugger to the running program.
The crash does not occur directly
Then you have to use a memory checker, such as valgrind
. The memcheck
tool will tell you about all memory access errors even if they don't throw segfault.
valgrind --tool=memcheck <your-program> <args> valgrind <your-program> <args> # memcheck is the default tool
Valgrind summary
valgrind <your-program> <args>
: memory checkervalgrind –db-attach=yes <your-program> <args>
: to automatically attach gdb on errorsvalgrind –leak-check=full <program> <args>
: to completely analyse memory leaksvalgrind –tool=massif –time-unit=B <program> <args>
+ms_print massif.<pid>
: statistics about which functions are using memoryvalgrind –tool=callgrind <program-compiled-O2> <args>
+kcachegrind callgrind.out.xxxx
+calgrind_control
: call profilingvalgrind –tool=cachegrind <program-compiled-O2> <args>
: CPU cache profiling in order to find cache misses
Always do profiling with optimization options of compiler, or you could optimize things that the compiler already automatically does.
GDB Summary
Starting
- #
gdb <prog-file>
- #
gdb –args <prog-file> <prog-args…>
: start gdb with program arguments - #
gdb <prog-file> <core-file>
: inspect the core dump - #
gdb <prog-file> <pid>
: attach to the running process
Running
run <prog-args…>
(short “r”) : start the programstep [count]
(short “s”) : step one linestepi [count]
(short “si”) : step one instructionnext [count]
(short “n”) : step one line without entering in functionscontinue
(short “c”) : continue the programfinish
(short “fin”) : execute until selected stack frame returnsadvance [source-file]:<line>
(short “adv”) : continue up to the given locationcall <func-name>
(short “ca”) : call a function (the context is copied so that it is not modified)kill
(short “k”) : stop the program
Navigating
backtrace
(short “bt”) : show the stackframe <frame-number>
(short “f”) : move to the stack drame numberlist [source-file]:<line|function>
(short “l”) : show source code
Threads
thread <thread-num>
(short “t”) : switch to threadinfo threads
(short “i th”) : show list of current threads
Breakpoints
break [source-file]:<line|function> [thread <thread-num>] [if <condition>]
(short “b”) : set a breakpointinfo breakpoints
(short “i b”) : show all current breakpointscondition <breakpoint-number> <condition>
(short “cond”) : specify the breakpoint to break only if condition is truedelete breakpoints <breakpoint-number>
(short “del b”, “del”) : delete a breakpointenable/disable <breakpoint-numbers…>
(short “en” and “dis”) : enable or disable some breakpoints
Inspecting data
print <var-name>
(short “p”) : print the value/content of the variableprint *<pointer>@<nelements>
: print nelements of the arrayprint/<format> <var-name>
: print with a certain format (x for hexa, …)display <var-name>
(short “disp”) : display the value/content of the variable at every stepawatch <var-name>
(short “aw”) : stops the execution whenever the variable is read or writtenwatch <cond-on-var>
(short “wa”) : stops the execution whenever the condition on the variable becomes trueptype <var-name>
: type of variablex <addr>
: print the content of memory, can format with /<format> tooset variable <var-name> = <value>
: change variable value
Automation
source <file-name>
: load a set of commands from a file- You can define macros in ~/.gdbinit
Errors prevention
It is interesting to know the sooner possible about problems. You should then use the assert()
macro to check all of your parameters or variables that could cause a crash or an error. When debug is not enabled, there will be no code produced and thus no overhead.
You should enable core dumps in your shell (see Segmentation Faults), so that you can watch variables content to have information about the other variables that the one which failed the assert.
If you write your own assert macro, you should call the abort()
function to create the core dump file.
If you don't want to save core dumps, you can still catch the sigabrt signal, freeze the program and attach a debugger. You can even unfreeze the program with the debugger (eg by changing a variable content), and continue the program to see what happens.
System calls
strace
prints a list of system calls made by the program.
Classic compilation errors
Or not so classic…
error: template with C linkage
This happens when you are declaring templates inside an extern “C”
environment. This usually occurs when you include a header with C++ and templates from a C header with extern “C”
.