IBM®
Skip to main content
    United States change      Terms of use
 
 
Select a scope:    
     Home      Products      Services & industry solutions      Support & downloads      My account     
alphaWorks  >  Systems management  >  

Memory Interceptor Library

A shared library that intercepts standard memory calls: malloc, calloc, realloc, free, etc., from binary applications and analyzes a program for memory leaks.


Date Posted: February 5, 2004
Overview Requirements DownloadFAQsForum Reviews

1. What is the Memory Interceptor Library used for?
2. Where can the Memory Interceptor Library be used?
3. What are the performance implications when using the Memory Interceptor Library?
4. What are the limitations and known problems?
5. Can I modify the source code?
6. What are your plans for future releases?


1. What is the Memory Interceptor Library used for?

The Memory Interceptor Library is used to intercept native memory calls for existing programs that were written using the C programming language. As each memory call is intercepted, a back trace is performed on the program stack; this trace is then forwarded with additional information, such as the type of memory operation, size of memory, process ID, etc., to a remote application where it can be further analyzed for memory leaks.
Back to top Back to top

2. Where can the Memory Interceptor Library be used?

You do not need to source code of the original program that you would like to analyze for memory leaks. You also do not have to re-link the application. It can be used on either AIX- or Linux-based systems. See the SYSTEMREQ file for further requirements. The memory interceptor library can be used with any C-based program that was linked as "shared" or "dynamic" and that uses the standard C memory allocations and de-allocations: malloc, calloc, realloc, and free (valloc on AIX). The memory interceptor library cannot be used with applications that are linked as "static" or any application that bypasses the standard memory heap allocators as provided by libc.
Back to top Back to top

3. What are the performance implications when using the Memory Interceptor Library?

The performance overhead is based on the following:
  • How many memory operations an application makes. The actual intercepting of memory calls has an overhead of close to 0%.
  • The network bandwidth between the memory interceptor library and the remote application. Typically, the remote application should reside on the same LAN; for example, a laptop computer. With a 100-MB Ethernet LAN, the overhead is typically less than 1% for normal applications and a network that is not congested.
  • The depth of each stack back-trace. Change the environment variable "MEMCHECK_STACK" to either reduce or increase the number of stack frames to include per memory operation. (See the file "setpreload".) The maximum value is set to 6. If you need a larger stack frame, please contact the author for modifications. For a value set at 6, on AIX systems the overhead is close to 0% and for Linux systems is on the order of 1%.
  • Whether or not symbol look-ups are turned on or off. The symbol look-up option is turned either on or off using the "MEMCHECK_SYMBOLS" environment variable. (See the file setpreload.) With this option turned on, the overhead is approximately 20% on Linux systems and 4% on AIX systems. Further work could be performed to reduce this overhead on Linux by effectively improving the searching of addresses corresponding to function names for Linux. There are some current problems in correctly identifying what the corresponding function name is for a particular address on AIX. An alternative is to use one that the applications included with AIX, such as "genld", to show symbols for a running application.
Back to top Back to top

4. What are the limitations and known problems?

Many applications do not free all memory that was allocated. This is particularly true for short-lived applications such as "ls". For performance reasons, it is easier to let the application terminate where its heap will be reclaimed rather than freeing each individual memory block. These blocks will show up as memory leaks, although they are not true memory leaks. The library interceptor will work only with C programs linked with dynamic libraries. In addition, applications that make use of their own memory pool will not be able to use the features in the library interceptor. C++ programs that use the new operator will also not be able to use the memory interceptor. Other potential problems can occur with programs that modify or alter the environment variables: for example, a program that uses one of the exec() system calls but does not pass the entire environment list. For applications that do not pass the environment list, you can hardcode the MEMCHECK values as shown in memcheck.h. For applications that modify either LD_PRELOAD or LIB_PATH, there is no known solution. For the AIX version, the memory interceptor library will not work with applications linked with either the DCE or 128 variations of the compiler (cc_r4, xlc_r4, xlc128, cc128). Applications linked using any of these compilers will not be affected and will work as normal.
Back to top Back to top

5. Can I modify the source code?

The source code can be easily modified to include more debugging information, to increase the number of stack frames to save, etc. Please contact the author for further information.
Back to top Back to top

6. What are your plans for future releases?

Future releases will include the following:
  • Improve address symbol resolution for AIX.
  • Improve efficiency of address symbol resolution for Linux.
  • Add additional support for AIX DCE and 128 variations of the compiler.
  • Add support for additional platforms (HP, Sun).
  • Add additional support within the memleak application for leak detection using trends, etc.
Back to top Back to top
Download now Download now

Related technologies

For platform(s):
Multi-Platform

For topics:
AIX, C, memory leak, Unix, debugging, analysis


 

    About IBM Privacy Contact