Chapter 03 - The Core --------------------- "Earth has a deadline." [The Core, movie, very bad... actually, even worse] = 03.01 === Cores ========================================== In case a fatal error occurs during run time, the operation system is forced to eliminate this process. This can be the case if a program tries to write into memory segments which do not belong to it. E.g. if the index of an array is too large or if a pointer is used, which was not initialized or is not valid anymore. The result is a 'segmentation fault'. To allow a reproduction of the state the program was in, when the error occurred, a core is dumped. I.e. the complete memory segment containing the binary and all its allocated memory resources are written to a file - called 'core'. Usually the core is not written since the normal user has no interest and not the means to debug any program which crashes from time to time. So, during developing and debugging your own source code, the system needs to be told to write a core. The 'limit' command shows usually this: #> limit cputime unlimited filesize unlimited datasize unlimited stacksize 8192 kbytes coredumpsize 0 kbytes memoryuse unlimited vmemoryuse unlimited descriptors 1024 memorylocked unlimited maxproc 2047 The core dump size is 0, preventing cores to be written. Use the following command to enable the writing of cores: #> limit coredumpsize unlimited = 03.02 === Debugger ======================================= To read the information preserved within the core a so called 'debugger' is needed. On Unix-machines usually the GNU Debugger (gdb) is installed. The debugger loads the binary and the appropriate core file: #> gdb my_binary core This may take a while :) The documentation of the gdb can be found here: http://www.gnu.org/software/gdb/gdb.html = 03.03 === The Call Stack ================================= One of the most important information contained within the core is the last status of the call stack. It lists all the called functions and the line numbers from where the next function was called. To make the gdb show the call stack type: gdb> where Here, also the values of the input parameter for each function can be seen. If a member function of an object is called, also the parameter 'this' is shown. If its value is 0 then a not existing object has been used. This indicates, that a pointer to this object was not really initialized and probably NULL. To move the stack up and down the commands gdb> up gdb> down can be used. To see the current portion of source code - if available - the command gdb> list can be used. To show the value of a variable - within the current context - use the 'print' command: gdb> print my_variable gdb> print my_pointer gdb> print *my_pointer To end the gdb type: gdb> quit A debugger can be used for much more (interactively step through a running program), but also with these few commands a lot of information can be gathered to find the error. To get a real GUI (graphical user interface) - instead of just a command line interface - take a look at 'ddd - DataDisplayDebugger' which is just that: a graphical front-end for command-line debuggers such as the gdb. http://www.gnu.org/software/ddd/