====== Debugging ======

If you look directly at gcc output, you should install [[software:colorgcc|ColorGCC]] which displays errors in red and warning in yellow.

===== 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 [[software:gdb|GDB]] to watch variable contents.

You have several possibilities to get into the program where the segfault occurred :
  * run the program with [[software:gdb|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; the ''file'' command tells you which program created the core dump), and inspect the core dump with [[software:gdb|GDB]].
  * [[howtos-tips#catching_signals|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 [[software:valgrind|Valgrind]]. The ''memcheck'' tool will tell you about all memory access errors even if they don't throw segfault.

<code bash>
valgrind --tool=memcheck <your-program> <args>
valgrind <your-program> <args> # memcheck is the default tool
</code>

===== Memory leaks =====

The solution is again [[software:valgrind|Valgrind]]:
<code bash>
valgrind --leak-check=full <program> <args>
</code>



===== 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 [[howtos-tips#catching_signals|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"''.