IBM Support

Memory leaks are reported outside of the instrumented code

Technote (troubleshooting)


Attempts to instrument C++ code with IBM Rational Test RealTime result in memory leaks (MLK) reported outside of the instrumented code.


You see the memory leaks without any link to the source code in Test RealTime. You see the following description.

This <size> byte block was allocated before or after the top-level
instrumented function has been called.


This behavior might be due to the construction of the static object with C++ code.

Resolving the problem

Most of the time the reported MLK are correct. MLK reported outside of the instrumented code are difficult to locate. To find them consider the following steps.

  1. Debug your application.

  2. Track blocks that the compiler has allocated when creating a class.

  3. Verify whether the compiler has released those blocks or not.


When testing C++ code, you could explain that Test RealITime can do an allocation at the construction of the static object. The message reports allocation of blocks before the entry program or after the exit. That means: the code has called malloc before the application starts. Therefore the pointer is not visible from the instrumented code. In that case you only have the size.Test RealTime can not link the code at the malloc, because it was not instrumented.

Instrumenting an application for memoryProfiling consists of multiple steps.

  1. Wrap the call to malloc/free (and other heap management functions) into all parsed files (even if they are not instrumented)

  2. Instrument all functions to create a chained list through the called methods in order to have the complete call stack available when the _atp_alloc get called.

  3. For C++ only: the wrap of the std new/delete. This step is done by the runtime through the std new delete redefinition.

Document information

More support for: Rational Test RealTime
Runtime Analysis: C++

Software version: 7.5,, 8.0,,,

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

Reference #: 1594773

Modified date: 19 March 2013

Translate this page: