SuSE GmbH

SuSE Support Database

Title: Debugging with Glibc

----------

Mainpage o Searchform o History o Versions o Categories o Contents

----------

Debugging with Glibc

Applies to

glibc: Version 2.1

Debugging your applications with glibc

This article points out some ways to use features of the GNU C library (glibc) 2.1 (or newer) to help in debugging applications and libraries. These features give you additional debugging possibilities in comparison with a normal debugger like gdb, or trace utilities like strace and ltrace.

Glibc comes with its own manual that documents most of these areas already. Instead of duplicating the information, I'm just giving pointers. In same cases documentation is missing and can only be found here.

Debugging features of glibc:

Malloc related

The malloc implementation in glibc is much less forgiving than most other malloc implementations. For example, if you call free more than once on a pointer allocated with malloc, or overwrite the malloced space by just one byte, you might get a segmentation fault with glibc---where other system's libraries never complained before. This is a feature of glibc's malloc since it helps to find those bugs.

Let me state this differently again: A segmentation fault in one of the malloc routines, e.g. __free or chunk_alloc is always the result of a bug in the usage of the malloc routines. Don't start complaining about bugs in glibc's malloc - it's (so far;-) always a bug in the user program.

Besides the segmentation faults, glibc comes with a number of tools to help debugging memory related problems. Most of these tools need recompilation of the program but some not.

Consistency checks

A possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_ (there's a trailing underscore---don't forget it). When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result.

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. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

Another possibility is to compile your program with memory checking enabled. For details see the glibc manual (call info libc "Heap Consistency Checking").

Fishing for Memory Leaks

Finding memory leaks manually is quite difficult since it involves checking all malloc and free calls. Glibc comes with a tool to do this for you, it's called mtrace. A detailed description is part of the glibc manual. To read the section, you can run info libc "Allocation Debugging".

Getting a stacktrace

If a program dies with a segmentation fault, you can get a stacktrace with the command catchsegv. Just call it with the program that's producing segfaults as argument, e.g. catchsegv buggy.

To produce a stacktrace in your program, the backtrace functions from <execinfo.h> can be used.

Problems with dynamic libraries

For debugging the dynamic linking of programs, the dynamic linker can be instructed to output various kinds of debugging messages. The debugging output is requested with the environment variable LD_DEBUG. Setting it to help, gives a list of options. For example, the output of LD_DEBUG=help ls is:
Valid options for the LD_DEBUG environment variable are:

  bindings  display information about symbol binding
  files     display processing of files and libraries
  help      display this help message and exit
  libs      display library search paths
  reloc     display relocation processing
  symbols   display symbol table processing
  versions  display version dependencies

To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
If you want to use more than option, you should separate them by commas, e.g. LD_DEBUG=files,libs program.

The program ldd gives a list of all libraries that a program (or a library) depends on.

----------

Keywords: DEBUGGING, MALLOC, GLIBC

----------

Categories: Development Tools

----------

Feedback welcome: Send Mail to aj@suse.de (Please give the following subject: SDB-aj_debug)

----------

Mainpage o Searchform o History o Versions o Categories o Contents

----------

SDB-aj_debug, Copyright SuSE GmbH, Nuremberg, Germany
SuSE GmbH - Last generated: 25. Nov 1999 15:59:30 by aj with sdb_gen 1.00.0