iCan Blog Archive

Support for a new heap memory manager, entitled the debug memory manager, was added to the 6.1 release with PTF SI33945 and is included in the base operating system in subsequent releases.

The debug memory manager is used primarily to find incorrect heap usage by an application. It’s not optimized for performance and may negatively affect the performance of the application. However, it’s quite valuable in determination of incorrect heap usage.

Memory-management errors are sometimes caused by writing past the end of an allocated buffer.  Because this often has no immediate consequence, symptoms don’t arise until much later when the memory that was overwritten (usually belonging to another allocation) is referenced and no longer contains the expected data.

The debug memory manager allows detection of memory overwrites, memory overreads, duplicate frees, and reuse of freed memory. Memory problems detected by the debug memory manager result in one of two behaviors. If the problem is detected at the point that the incorrect usage occurs, an MCH exception message (typically an MCH0601, MCH3402, or MCH6801) will be generated. In this case, the error message typically stops the application. If the problem isn’t detected until later, after the incorrect usage has already occurred, a C2M1212 message will be generated. In this case, the message doesn’t typically stop the application.

The debug memory manager detects memory overwrites and memory overreads in two ways:

  • First, it uses restricted-access memory pages. A memory page with restricted access is placed prior to and after each allocation. Each memory block is aligned on a 16-byte boundary and placed as close to the end of a page as possible. Since memory protection is only allowed on a page boundary, this allows the best detection of memory overwrites and memory overreads. Any read or write from one of the restricted access memory pages will immediately result in an MCH exception. 
  • Secondly, it uses padding bytes prior to and after each allocation.  A small number of bytes immediately prior to each allocation are initialized at allocation time to a preset byte pattern. In addition, any padding bytes following the allocation required to round the allocation size to a multiple of 16 are initialized at allocation time to a preset byte pattern. When the allocation is freed, all of the padding bytes are verified to ensure they still contain the expected preset byte pattern. If any of the padding bytes have been modified, the debug memory manager generates a C2M1212 message with reason code X’80000000′, indicating this fact.

The debug memory manager isn’t enabled by default, but is enabled by setting the QIBM_MALLOC_TYPE environment variable to the value ‘DEBUG’.  An example of how to do this is as follows:


Any applications started while this environment variable setting is in effect will use the debug memory manager rather than the default memory manager. This should allow easier detection of application heap problems.

Please note the QIBM_MALLOC_TYPE environment variable is checked only once per activation group, at the first heap function that’s called within the activation group. To ensure the environment variable is used, it should be set up prior to the creation of the activation group.

The debug memory manager isn’t appropriate for full-time, constant or system-wide use.  Although it’s designed for minimal performance impact on the application being debugged, significant negative impact on overall system throughput can result if it’s used on a system-wide basis. The debug memory manager should only be used to debug single applications or small groups of applications at the same time. Using the debug memory manager on a system-wide basis isn’t recommended and may cause significant system problems, such as excessive use of the system auxiliary storage pool (ASP).

Scott recently published a complete article, “Mastering ILE Heap Memory Management,” for SystemiNetwork that you can read for much more information on heap memory management.

This blog article was written by Scott Hanson. Scott is a software engineer with twenty years of experience in analysis, design, implementation and support of complex software projects. His area of expertise concerns compilers and language runtimes associated with the compilers. Most of his experience has been with C and C++ compilers and the runtimes and libraries associated with those languages. Thanks, Scott!

This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.