search

johnsonjh / duma

duma: Detect Unintended Memory Access (D.U.M.A.) - A Red-Zone memory allocator
https://github.com/johnsonjh/duma
GNU General Public License v2.0
99 stars 10 forks source link
allocator c duma leak-detection malloc

readme

DUMA

license-gplv2 license-lgplv2.1 fossastatus codesize release codacy codebeat deepscan

Detect Unintended Memory Access

A Red-Zone memory allocator

Description

DUMA helps you detect two of the most common programming errors:

  1. Software that overruns the boundaries of a malloc() memory allocation,
  2. Software that touches memory allocations already released by free().

Unlike other malloc() debuggers, DUMA will detect read accesses as well as writes, and it will pinpoint the exact instruction that causes an error.

Electric Fence, the predecessor of DUMA, has been in use at Pixar since 1987, and at many other sites for years.

DUMA uses the virtual memory hardware of your computer to place an inaccessible memory page immediately after (or before, at the user's option) each memory allocation. When software reads or writes this inaccessible page, the hardware issues a segmentation fault, stopping the program at the offending instruction. It is then trivial to find the erroneous statement using your favorite debugger. In a similar manner, memory that has been released by free() is made inaccessible, and any code that touches it will get a segmentation fault.

Simply linking your application with libduma.a will allow you to detect most, but not all, malloc() buffer overruns and accesses of free memory. If you want to be reasonably sure that you've found all catch-able bugs of this type, you'll have to read and understand the rest of the documentation.

Besides catching these kind of memory bugs, DUMA also provides a means to detect memory leaks. When using DUMA to pinpoint the source of a memory-leak, some source modification is necessary - at the minimum, adding #include "duma.h" to your source.

Installation

DUMA may be installed from compiled binary packages or built from source code.

Binary Packages

Building from source

GNU Make

DUMA may be built using GNU Make.

GNU Make is available for many operating systems, including SunOS / Solaris, GNU/Hurd, AIX, HP-UX, BSD, GNU/Linux, and Microsoft Windows (using Cygwin or UWIN for POSIX compatibility, or natively with the MSYS / MINGW environment.)

GNU Make is often installed as gmake, but may be installed under a different name, such as mingw32-make, mingw64-gmake, or simply make (especially on GNU systems such as Linux).

Some non-GNU "Make" systems may work, but are untested and not recommended for building DUMA.

CMake

CMake is a portable suite of tools to automate the configuration, building, testing, packaging, and installation of software.

DUMA may be built using CMake 3.1 (December 2014) or later.

Visual Studio

Environment Notes

DUMA should work out of the box on most systems, however, specific environments may require additional configuration or warrant special consideration.

Solaris
BSD
ARM CPUs
MIPS CPUs
RISC-V CPUs

Usage

Static linking

Dynamic linking

Recommended Usage

Global and Environment Variables

DUMA has several configuration switches that can be enabled via the shell environment. These switches change what bugs DUMA will detect, so it's important that you know how to use them.

Word-Alignment and Overrun Detection

There is a conflict between the alignment restrictions that malloc() operates under and the debugging strategy used by DUMA. When detecting overruns, DUMA malloc() allocates two or more virtual memory pages for each allocation. The last page is made inaccessible in such a way that any read, write, or execute access will cause a segmentation fault. Then, DUMA malloc() will return an address such that the first byte after the end of the allocation is on the inaccessible page. Thus, any overrun of the allocation will cause a segmentation fault.

It follows that the address returned by malloc() is the address of the inaccessible page minus the size of the memory allocation. Unfortunately, malloc() is required to return word-aligned allocations, since many CPUs can only access a word when its address is aligned. The conflict happens when software makes a memory allocation using a size that is not a multiple of the word size, and expects to do word accesses to that allocation. The location of the inaccessible page is fixed by hardware at a word-aligned address. If DUMA malloc() is to return an aligned address, it must increase the size of the allocation to a multiple of the word size.

In addition, the functions memalign() and valloc() must honor explicit specifications on the alignment of the memory allocation, and this, as well can only be implemented by increasing the size of the allocation. Thus, there will be situations in which the end of a memory allocation contains some padding space, and accesses of that padding space will not be detected, even if they are overruns.

DUMA provides the variable DUMA_ALIGNMENT so that the user can control the default alignment used by malloc(), calloc(), and realloc(). To debug overruns as small as a single byte, you can set DUMA_ALIGNMENT to 1. This will result in DUMA malloc() returning unaligned addresses for allocations with sizes that are not a multiple of the word size. This is not a problem in most cases, because compilers must pad the size of objects so that alignment restrictions are honored when storing those objects in arrays. The problem surfaces when software allocates odd-sized buffers for objects that must be word-aligned. One case of this is software that allocates a buffer to contain a structure and a string, and the string has an odd size (this example was in a popular TIFF library).

If word references are made to un-aligned buffers, you will see a bus error (SIGBUS) instead of a segmentation fault. The only way to fix this is to re-write the offending code to make byte references or not make odd-sized allocations, or to set DUMA_ALIGNMENT to the word size.

Another example of software incompatible with DUMA_ALIGNMENT set less than the system word-size is the strcmp() function and other string functions on SunOS 4, which make word-sized accesses to character strings, and may attempt to access up to three bytes beyond the end of a string. These result in a segmentation fault (SIGSEGV). The only way around this is to use versions of the string functions that perform byte references instead of word references.

Catching the Erroneous Line

Using DUMA - and one of the following strategies - you can determine the offending line(s) of your source code responsible for causing an error.

Live (debugger control)

  1. Compile your program with debugging information and statically linked to DUMA. On some systems, including some Linux distributions, the linking order is crucial - DUMA must be the last library passed to the linker.
  2. Start your program from debugger e.g. with gdb <program>
  3. Set program environment variables such as 'set environment DUMA_PROTECT_BELOW 1'
  4. Set your program arguments with 'set args …'
  5. Run and wait for the segmentation fault

Post-mortem (core analysis)

  1. Compile your program (with debugging information).
  2. Set ulimit -c unlimited to get core files
  3. Start your program, choose one of following options
    • Start your program (linked statically with DUMA)
    • Start your program with duma.sh <your_program>
  4. Wait for a segmentation fault. This should have created a core[.<pid>] file, which you can examine (i.e. gdb <program> -c <core file>)

Debugging your Program

General Debugging Instructions

  1. Link with libduma.a as explained above, ensuring proper linking order.
  2. Run your program in a debugger and fix any overruns or accesses to free memory.
  3. Quit the debugger.
  4. Set DUMA_PROTECT_BELOW = 1 in the shell environment.
  5. Repeat step 2, this time repairing under-runs if they occur.
  6. Quit the debugger.
  7. Optionally, read and install gdbinit.rc as ~/.gdbinit if you are using the gdb debugger

Word-Alignment and Overrun Debugging

Memory Usage and Execution Speed

Memory Leak Detection

C++ Memory Operators and Leak Detection

Definition of own member new/delete Operators

// const char * file  or  __FILE__ macro
// int          line  or  __LINE__ macro

// scalar new throwing bad_alloc() on error
ptr = new(file,line) type;

// scalar new returning 0 on error
ptr = new(std::nothrow,file,line) type;

// scalar delete
operator delete(ptr,file,line);

// vector new throwing bad_alloc() on error
ptr = new(file,line) type[n];

// vector new returning 0 on error
ptr = new(std::nothrow,file,line) type[n];

// vector delete
operator delete[](ptr, file,line);

Compilation Notes for Release/Production

NO WARRANTY

Diagnostics

Bugs

Comparison with other tools

Availability

Releases

Git Repositories

NOTE: All source repositories are mirrors with identical contents.

Issue Tracking

Security Policy

Authors

 Copyright © 2020‑2022 Jeffrey H. Johnson <trnsz@pobox.com>
 Copyright © 2006 Michael Eddington <meddington@gmail.com>
 Copyright © 2002‑2021 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH
 Copyright © 1987‑1999 Bruce Perens <bruce@perens.com>

License

       FOSSASmallStatus

Version History