Memcheck Predefined Probe
Memory Corruption Check Probe: memcheck.ual
The memcheck.ual; predefined probe is useful for tracking down memory corruption in an application. Such corruption occurs for a number of reasons, but this probe checks for writing outside the bounds of allocated memory and double deallocations.
The probe works by:
* putting a "fence" at either end of each allocated item, and * keeping a list (in-memory) of all outstanding allocations * check that item has not been freed, and the fences are unchanged: * for an item when the item is freed * for all items when a "checkpoint" is taken (see below)
A "checkpoint" is a user-defined point at which to check all allocated items for corruption. By default the only checkpoints are on program exit and on signals handled by sigsegv.apc.
This probe assumes that all requests for allocations and deallocations of dynamic storage are made through calls to discrete run-time heap manager functions (e.g., malloc, free, etc.).
There can be any number of these allocation or deallocation functions, and some functions (e.g., realloc) may do both allocations and deallocations during the same call. Additional heap manager functions may be specified in addition to the default ones by adding your own probes to those provided by memcheck.ual.
Typically, the heap is a large repository of unused memory available for dynamic storage that is controlled by a heap manager. All requests for more memory (especially for dynamically sized objects) needed by a running application program are made to the heap manager. The heap manager carves the heap into smaller portions and allocates those portions upon request. In a well behaved application program, when those allocated portions of heap memory are no longer needed, they are deallocated by returning them to the heap manager for later reuse.
A typical source of heap memory corruption is for the program to overwrite the bounds of the allocated memory, thus destroying other program data and even the heap memory structure.
The memcheck probe helps the user identify heap corruptions from overwrites by recording all allocations and adding so-called "fences" to detect if the program writes beyond the allocated ob sect, and when objects are deallocated or the program terminates the fences are checked to make sure overwriting has not occurred.
Another source of corruption is deallocating an object that was already deallocated. The memcheck probe tests for double-deallocation problems and reports them.
* produce XML output * add periodic checking * keep track of frees and report double-frees like heap.apc does * check source, dest of memory move routines like aprobe v2's heap_corruption.apc * provide way of dynamically calling DoCheckpoint and Sigsegv_Callback without linking probes together?
Memcheck UAL Parameters
aprobe -u memcheck.ual [-p "[-h] [-v] [-d depth] [-e func] [-E func] [-S signum]"] your_program
- -d depth
- traceback depth for double deallocation reports. Default 9.
- -e func
- trigger a checkpoint on entry to the named function. Can be repeated. (Since 4.5.1)
- -E func
- trigger a checkpoint on exit to the named function. Can be repeated. (Since 4.5.1)
- -S signum
- trigger a checkpoint when the given signal is received (1-63). Default off. (Since 4.5.1)
- produces brief help text.
- means verbose mode, which produces additional progress messages.
Hint: use apostrophes (') and escaped quotes (\") to delimit function names for -e and -E options:
aprobe -u memcheck -p "-v -e 'extern:\"printf\" in \"libc.so\"'" main.exe
Hint: wildcards (*) can be used in function names.
aprobe -u memcheck -p "-v -e proc*" main.exe
You can control the behavior of the memcheck probe by calls from within their own probes. The API for the memcheck probe is defined by
$APROBE/include/memcheck.h. Some of the functions exported by
- ap_Memcheck_DoCheckpoint (ap_NameT Commentary);
check all allocated memory for corruption at this point.
Memcheck Demand Actions
demand.ual on the Aprobe command line:
aprobe -u memcheck -u demand myapp.exe
apdemand to send actions:
memcheck.ual responds to the following actions:
- memcheck checkpoint
Note that all actions containing the action string will be triggered.
Memcheck Performance Issues
The additional execution time caused by the memcheck probe is small (except for checkpoint overhead). This is because the memcheck probe only instruments a few specific functions, and the probe is tiny compared to the functions themselves (which are usually very computationally intensive).
The memcheck data requires quite a bit of memory. The amount of memory required is proportional to the number of outstanding allocations tracked. This will reduce the memory available to your application program. So, if your application program is close to the process or system memory limit, this could cause its allocations to fail, which could even kill the application.