1. install colorgcc
2. make sure ~/bin path is in your $PATH variable before /usr/bin
3. place symlinks in ~/bin/:

   cc  -> /usr/bin/colorgcc
   g++ -> /usr/bin/colorgcc
   gcc -> /usr/bin/colorgcc

4. create a ~/.colorgccrc file, and define inside the location of the real cc, gcc, g++ binaries:

   /usr/bin/cc, gcc, g++

Source: http://en.opensuse.org/Libzypp/Devel/colorgcc

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 :

• 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 gdb.
• catch the sigsegv signal and freeze the program, then attach the debugger to the running program.

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>

• # gdb <exec-file>
• # gdb <exec-file> <core-file> : inspect the core dump
• # gdb <exec-file> <pid> : attach to the running process

• run <program-parameters…> (short “r”) : start the program
• step [count] (short “s”) : step one line
• stepi [count] (short “si”) : step one instruction
• next [count] (short “n”) : step one line without entering in functions
• continue (short “c”) : continue the program
• finish (short “fin”) : execute until selected stack frame returns
• advance [source-file]:<line> (short “adv”) : continue up to the given location
• kill (short “k”) : stop the program

• backtrace (short “bt”) : show the stack
• frame <frame-number> (short “f”) : move to the stack drame number
• list [source-file]:<line|function> (short “l”) : show source code

• thread <thread-num> (short “t”) : switch to thread
• info threads (short “i th”) : show list of current threads

• break [source-file]:<line|function> [thread <thread-num>] [if <condition>] (short “b”) : set a breakpoint
• info breakpoints (short “i b”) : show all current breakpoints
• condition <breakpoint-number> <condition> (short “cond”) : specify the breakpoint to break only if condition is true
• delete breakpoints <breakpoint-number> (short “del b”, “del”) : delete a breakpoint
• enable/disable <breakpoint-numbers…> (short “en” and “dis”) : enable or disable some breakpoints

• print <var-name> (short “p”) : print the value/content of the variable
• display <var-name> (short “disp”) : display the value/content of the variable at every step

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.

strace prints a list of system calls made by the program.

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”.