On this page... (hide)
In general, when you have segfaults, it is best to try to run the thing with the debugger, like
[sergio@daq-pc scint]$ gdb ./scint (gdb) r novis.mac
when it stops do
it will give a so-called "stack trace", that will show you not just where the crash happened, which might be some very remote library function, but also from where in your code that function had been called. Find the line of the stack that belongs to your code, and check that the values passed have "sane" values (no NULL pointers, for example) by doing
In order to obtain all the possible information from the debugger, you must make sure that your whole program is compiled with the
-g switch, which enables the inclusion of debugging symbols in the executable. It may be helpful to also disable optimisations, using
-O0 (uppercase-o zero) at the end of the compiler switches or removing an existing
-Ox from them. For Geant4 makefiles, you can obtain this with setting
G4DEBUG:=true at the beginning.
Please note that if you instead run a Geant4 program in visualization mode, gdb may show an exception in the early 3D graphics setup phase:
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1208383808 (LWP 10751)] 0x07910f84 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/i915_dri.so
This is nothing to worry about, as it is properly handled in inside the 3D graphics driver where it occurs; just tell gdb to continue:
- gdb - the standard, text mode GNU debugger
- xgdb - a lightweigth GUI for gdb
- DDD Data Display Debugger - a more complete GUI for gdb, with data structures display
- A nice introduction to DDD, pretty good also for plain gdb.
- Insight a GUI for GDB from RedHat, the GDB mantainers.
- Emacs / XEmacs debug mode also provides an interface
- integrated in most IDEs
- gprof is the standard GNU profiler.
you have to recompile your program with profiling enabled to be able to use it.
- Valgrind is an advanced debugger/profiler/leak check/etc.
It is an absolutely amazing tool - its only problem with it is that your program will run 20-30 times slower when you debug it.
- oprofile System-level profiling using Pentium4/Athlon performance registers
when you don't want the profiler to interfere with your application, or you have to profile multiple applications/tasks interacting
- MemProf is a memory leak checker with a nice GUI; less sophisticated than Valgrind, but without the slowdown.
Unfortunately it is dead:
Due to issues interoperating with recent versions of the C library and toolchain, the memprof memory profiling and leak detection tool is no longer included in Red Hat Enterprise Linux 4. The memcheck and massif plugins to valgrind (which is newly included in Red Hat Enterprise Linux 4) provide similar functionality to memprof. (from http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-x86/)