Browse Prior Art Database

Method for detection and isolation of memory corruption errors

IP.com Disclosure Number: IPCOM000016423D
Original Publication Date: 2003-Jan-03
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 47K

Publishing Venue

IBM

Abstract

This article describes a method of detecting and isolating memory corruption errors in final production level programs. It makes use of a dynamically controllable trace facility combined with dynamically selectable memory consistency checking.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Method for detection and isolation of memory corruption errors

   When working in an environment where the programmer must use and manage allocated memory, it is easy for the programmer to make a mistake which leads to the corruption of a portion of that memory. Common examples of this are:

Allocating an array of structures and then iterating one time to many over the array. Using a pointer to allocated memory after having freed (deallocated) that memory. Casting a pointer (pointing to an allocated structure) to a different type of structure of different size.

Frequently the mistake does not cause an immediate problem, but rather causes an abnormal termination or other problem some time later such as when attempting to allocate new memory. This makes detection and isolation of the original mistake difficult, especially in long running and multi-threaded programs such as server programs.

Many compilers provide options to perform additional checking of allocated memory regions (heaps) during memory management calls, and provide . These help find basic problems, but usually impose a severe performance penalty, and require a recompile/relinking of the code to run in such an environment. If the performance impact is unacceptable for the final product, then this technique means that any programs tested this was do not really reflect the final product and cannot be used in a production (e.g. customer) environment. The technique described below addresses these issues. The technique requires that the target product contain internal tracing (preferrably dynamic); this is a common attribute of "industrial strength" programs and systems.

The technique consists of two parts:

Providing a mechanism to dynamically trace memory management calls. This can be done via

This allows the performance impacting consistency checks to be turned on only when needed, and to be isolated to those programs/threads/routines which are suspect thus greatly reducing the impact on the total system. It also greatly enhances the isolation of the original error by bounding it to the lines of code executed between the dynamic trace points.

Figure 1 below lists program with an error in line 25. This error causes the loop to execute one to many times resulting in corrupted mem...