Difference between revisions of "Memcheck Predefined Probe"

From OC Systems Wiki!
Jump to: navigation, search
m (Memcheck UAL Parameters)
m (Background)
 
(2 intermediate revisions by the same user not shown)
Line 33: Line 33:
  
 
Another source of corruption is deallocating an object that was already deallocated.  The memcheck probe tests for double-deallocation problems and reports them.
 
Another source of corruption is deallocating an object that was already deallocated.  The memcheck probe tests for double-deallocation problems and reports them.
 +
 +
Memcheck can also reset the value of freed memory blocks to a specified value.  This can be useful when trying to find dangling pointers.  Note that blocks freed by realloc() cannot be reset.
  
 
=== Possible enhancements ===
 
=== Possible enhancements ===
Line 52: Line 54:
  
 
   
 
   
  aprobe -u '''memcheck.ual '''    [-p "[-h] [-v] [-d depth] [-e func] [-E func] [-S signum]"] your_program
+
  aprobe -u '''memcheck.ual '''    [-p "[-h] [-v] [-d depth] [-e func] [-E func] [-r val] [-S signum]"] your_program
  
 
where:
 
where:
Line 62: Line 64:
 
; '''-E func'''
 
; '''-E func'''
 
: trigger a checkpoint on exit to the named function. Can be repeated. (Since 4.5.1)
 
: trigger a checkpoint on exit to the named function. Can be repeated. (Since 4.5.1)
 +
; '''-r val'''
 +
: reset freed (not realloc'ed) memory blocks with the 8-bit value specified.  Default off. (Since 4.5.1)
 
; '''-S signum'''
 
; '''-S signum'''
 
: trigger a checkpoint when the given signal is received (1-63).  Default off. (Since 4.5.1)
 
: trigger a checkpoint when the given signal is received (1-63).  Default off. (Since 4.5.1)

Latest revision as of 22:44, 14 August 2019


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.

Assumptions

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.

Background

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.

Memcheck can also reset the value of freed memory blocks to a specified value. This can be useful when trying to find dangling pointers. Note that blocks freed by realloc() cannot be reset.

Possible enhancements

* 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?


Usage

This probe is applied at run time using aprobe as described in Ual Parameters below.


Memcheck UAL Parameters

memcheck.ual is specified on the aprobe command line or in an APO file as described in Command Line. The specific options are:


aprobe -u memcheck.ual     [-p "[-h] [-v] [-d depth] [-e func] [-E func] [-r val] [-S signum]"] your_program

where:

-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)
-r val
reset freed (not realloc'ed) memory blocks with the 8-bit value specified. Default off. (Since 4.5.1)
-S signum
trigger a checkpoint when the given signal is received (1-63). Default off. (Since 4.5.1)
-h
produces brief help text.
-v
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

Memcheck API

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 memcheck.ual are:

ap_Memcheck_DoCheckpoint (ap_NameT Commentary);

check all allocated memory for corruption at this point.


Memcheck Demand Actions

(Since 4.5.1).

You can control memcheck.ual using demand.ual and apdemand.

Include demand.ual on the Aprobe command line:

 aprobe -u memcheck -u demand myapp.exe
 

then use apdemand to send actions:

 apdemand checkpoint
 

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.