Development/malloc check

From KDE TechBase


Development/malloc check


MALLOC_CHECK_

MALLOC_CHECK_ is an environment variable used by the GNU C Library (glibc) to automatically enable an extensive suite of debugging functions, which check for proper memory allocation, usage, and deallocation. It includes options to enable aborting a program as soon as a corruption is detected and for printing out error messages.

KDE's usage

KDE enables MALLOC_CHECK_ by default in development versions of KDE by setting the environment variable in the startkde script, from among the following possibilities:

  • MALLOC_CHECK_ is not set: When MALLOC_CHECK_ has not been set, then memory is used as normal with no special behavior. If bugs exist you may still receive "Segmentation faults" after the corruption has become severe enough to trip an operating system error routine.
  • MALLOC_CHECK_ = 0: Memory check code is enabled. However all errors are silently ignored without so much as a warning.
  • MALLOC_CHECK_ = 1: On error, a diagnostic message is printed on stderr.
  • MALLOC_CHECK_ = 2: On error, abort(3) is called without a diagnostic message. This is the value set by startkde for glibc versions less than 2.9.
  • MALLOC_CHECK_ = 3: abort(3) is called, and a diagnostic message is printed. This is the value set by startkde for glibc versions greater than or equal to 2.9. Earlier glibc versions were unnecessarily "noisy" with this variable set to 3.
Note
An exception to the automatic variable setting is that if MALLOC_CHECK_ is already set to a value when startkde is run, startkde will not change that value.


More information is available in the man page for malloc(3), and in the "Heap Consistency Checking" GNU info page for libc. (Konqueror users can open info:/libc/Heap Consistency Checking)

Crashes

This checking may reveal bugs in programs, with a " *** glibc: corruption detected" message (or similar). See an example of a crash because of this variable.

Note that these crashes are not bugs with MALLOC_CHECK_, but a bug in the program which has gone unnoticed up to this point.

Note
There is a possible bug with glibc 2.10.1's memory checking for x86_64 systems using KDE 4 and glib. See KDE bug #196207.


If you are a developer experiencing crashes due to this checking and you are unable to diagnose the source of the bug, it may be fruitful to use the Valgrind tool to search for the source of the error.