Debugging on Ember

The GNU gdb debugger is available and may be used with serial programs or core files from serial or parallel programs. For information on  using gdb see the online man page and the  gdb user manual. 

The ddd graphical interface for gdb is available on the login node. ddd can be used with c, c++, fortran, and perl source code. See the ddd user guide for more information and examples.

The Intel debugger idbc is installed along with the Intel compilers.For more information on the Intel debugger, see : idbc -help . idbc is similar to gdb in operation and it will recognize most gdb commands if started with the -gdb flag. idbc works well with C, C++, and Fortran codes.

The Totalview debugger [with graphical user interface] works with the supported MPI environment. It is our recommended debugger for MPI code.

Information on starting Totalview on Ember (and other NCSA platforms) can be found here.

Totalview documentation can be found in /usr/apps/tools/toolworks
/totalview/doc and on the Etnus website here.

Valgrind can detect memory management bugs and threading bugs in c/c++ code. Since valgrind can add lots of diagnostic information to output and slow execution, it's best used only when debugging. 

C/C++ programs using malloc(), calloc(), or realloc() can set the  MALLOC_CHEC_ env. variable.  From "man malloc": If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately.

Set the MPI_CHECK_ARGS environment variable to enable runtime checks of MPI function calls. MPI_CHECK_ARGS (toggle) Enables checking of MPI function arguments. Segmentation faults might occur if bad arguments are passed to MPI, so this is useful for debugging purposes. Using argument checking adds several microseconds to latency. Default: Not enabled

The techniques for trapping floating point exceptions [which are not always bugs] vary by compiler and operating system.  Since each case is a little different, see the link at left for the examples that match your situation.  Fortran compilers tend to have a more straightforward approach to floating point exceptions than c compilers.

Splint [for c code] and ftnchek [fortran] are available on ember.  While not true debuggers, source code analysis tools can be very helpful when trying to track down a program bug.  They can also help you write clean maintainable code by providing useful feedback about coding style, unused variables, non-portable practices, ...   Don't be alarmed by the number of warnings generated by these tools, they're designed to detect a great variety of potential problems.

Strace produces a system call trace for any program you can run.

Each line in the trace contains the system call name as used by your program, followed by  its arguments in parentheses and its return value.

If you know what sort of system call may be failing, strace can be quite powerful.

For more information, see-

man strace

ltrace produces a library call trace for any program you can run.

Each line in the trace contains the library call name as used by your program, followed by  its arguments in parentheses and its return value.

If you know what sort of library call may be failing, ltrace can be quite powerful.

For more information, see-

man ltrace