Difference between revisions of "Memcheck Predefined Probe"

From OC Systems Wiki!
Jump to: navigation, search
(Created page with " == Memory Corruption Check Probe: memcheck.ual == The '''memcheck.ual;''' predefined probe is useful for tracking down memory corruption in an application. Such corruption...")
 
m (Memcheck UAL Parameters)
Line 54: Line 54:
  
 
   
 
   
  aprobe -u '''memcheck.ual '''    [-p "[-h] [-v] [-e func] [-E targfuncet] [-S signum]"] your_program
+
  aprobe -u '''memcheck.ual '''    [-p "[-h] [-v] [-d depth] [-e func] [-E func] [-S signum]"] your_program
  
 
where:
 
where:
  
 +
; '''-d depth'''
 +
: traceback depth.
 
; '''-e func'''
 
; '''-e func'''
 
: trigger a checkpoint on entry to the named function. (Since 4.5.1)
 
: trigger a checkpoint on entry to the named function. (Since 4.5.1)
Line 68: Line 70:
 
; '''-v '''
 
; '''-v '''
 
: means verbose mode, which produces additional progress messages.
 
: means verbose mode, which produces additional progress messages.
 
  
 
=== Memcheck API ===
 
=== Memcheck API ===

Revision as of 22:16, 20 February 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 only checks for writing outside the bounds of allocated memory.

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 takes no config file -- the idea is to keep it simple but make it easy to edit and rebuild locally:

apc memcheck.apc sigsegv.ual

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.

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] [-S signum]"] your_program

where:

-d depth
traceback depth.
-e func
trigger a checkpoint on entry to the named function. (Since 4.5.1)
-E func
trigger a checkpoint on exit to the named function. (Since 4.5.1)
-S signum
trigger a checkpoint when the given signal is received. (Since 4.5.1)
-h
produces brief help text.
-v
means verbose mode, which produces additional progress messages.

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.