Project summary

DBGMEM is a feature rich memory debugger for C and C++ programs; it currently works for Linux only. DBGMEM is released under the terms of the GNU Lesser General Public License

The tool helps you to find problems such as
  1. memory leaks
  2. heap memory corruption
  3. Misuse, illegal argument to selected standard library functions.
  4. stack corruption
  5. Use of freed or un-initialized heap memory.
  6. Allows you to extend the tool, check additional API's arguments
The tool overrides GLIBC memory allocation functions, memory and string manipulation functions in order to add its features.

The tool does not require any changes to your program, though you might wish to change your program in order to use some advanced features.

Contact information

To contact the developer please mail
moser - then comes a dot - michael - then comes the at sign - gmail dot com

Formal description of this product

DBGMEM is an open source memory debugger for C and C++ programs and runs under the Linux operating system, and is released under the GNU Lesser General Public License. DBGMEM adds debugging checks to parts of the of Glibc standard library; it is implemented as shared libraries that are loaded into the address space of the debugged process.


DBGMEM has several memory debugging tools, each can be loaded into the debugged program; The Simple tool keeps track of all allocated memory blocks, and adds book keeping information, such as the stack at the time when the block was allocated, into an arena header that precedes the allocated memory block; it also adds a guard word before and after the allocated block; The simple tool is best used for detection of memory leak problems; as the arena header can get corrupted by the program that is being debugged. The checking took keeps all book-keeping information off the stack in an anonymous Memory-mapped file; this makes the tool more robust to withstand memory overwriting bugs. The checking tool also adds ability to quickly look up information on any heap block for a pointer value contained within that heap block; the checking tool adds validation of parameters to common string and memory manipulation functions, and checks for possible stack smashing by these functions.


The tool helps you to find problems such as
  1. memory leaks; this applies to both the checking tool and simple tools. The tool tracks each allocated heap block together with stack trace taken at the time when the block was allocated; additionally an integer tag is kept with each allocation, this value tracks a logical period / `generation' that characterizes the time when the block was allocated. A report of this information is always produced on process exit, or when requested by the user. This information helps to find instances and causes of memory leaks.
  2. Use of not initialized heap memory or freed heap memory; this applies to both the checking tool and simple tools. The tool sets all newly allocated memory to byte value 0xDD and all freed memory to byte value 0xEE; use of these values usually leads to program errors, if this memory area contains a pointer, then dereferencing of a pointer with value 0xDDDDDDDD will lead to a crash.
  3. Heap memory corruption; this applies to both the checking tool and simple tools . The tool checks for memory overwrites and underwrites by placing a memory prefix and suffix on each heap block; if the value of the suffix is changed then a heap overwrite / underwrite is detected.
  4. This applies to the '''checking tool''' only; Misuse of string manipulation functions of GLIBC and memory copy/move functions of GLIBC; stack corruption by those checked functions The tool gets a first pass on common standard library functions, it is checked that the function will not overwrite an existing argument heap block; it is also checked that the stack of the calling thread will not be corrupted.

Mode of operation

You can run most programs with the debugger as is; the tool does not require the debugged program to be linked with any specific libraries; The tool is a shared library that is loaded into the address space of a process that is checked by means of the technique of DLL Injection. The LD_PRELOAD feature of the Dynamic linker is used to load the tools shared library first, before any other library is loaded; memory allocation and string manipulation function are intercepted and first called from the tool library; this enables the tool to add its checks. During runtime of the debugged process a raw report is written which is further processed after termination of the debugged process; the augmented report adds symbolic function names to stack traces contained in the raw report. The Gdb debugger is used to turn numeric addresses into symbolic addresses during further processing of raw report.