分析AIX上的native内存泄露

Running native profiling on AIX

Read the information provided

<!-- -->Introduction

AIX provides a debug extension to the malloc subsystem for debugging memory allocation errors and native memory leaks. This extension activates trace points in the malloc routines and records allocations that are not subsequently freed. This tool can be used to identify the source of leaking native memory in the Java process.

<!-- -->Running AIX debug malloc for a Java process

As AIX debug malloc is built into the malloc routines, you do not have to install additional tooling or utilities. To activate AIX debug malloc, set the following environment variable:

    MALLOCDEBUG=[trace,output:malloc.out,report_allocations,verbose,stack_depth:3] 

where the options have the following meanings:

trace	Activate tracing of the malloc subsystem.
output	Specify tracing to a log file; in this case, malloc.out.
report_allocations	Report outstanding allocations when the application stops.
stack_depth	Report outstanding allocations with the specified stack depth; in this case, 3.

Notes:

1. The stack depth of 3 provides only a limited stack trace. However, the use of larger stack depths with a Java application can cause crashes because the debug malloc facility does not understand the stack frames used for JIT compiled code.
2. Some of these options are available only in AIX 5.3

Because the report provided shows the stack trace for every outstanding allocation, it is often useful to combine entries with the same stack trace and to total the outstanding memory against that stack trace.

The following developerWorks article describes the usage of AIX debug malloc and provides a simple script to combine similar stack traces: http://www.ibm.com/developerworks/aix/library/au-mallocdebug.html?ca=dgr-lnxw82MALLOCDEBUG

<!-- -->Example of AIX debug malloc output

When the Java process stops, a report is written to either stdout or to the specified file, in the following format:

    Allocation #1111: 0x3174BC68 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1112: 0x3174C078 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1113: 0x3174C488 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1114: 0x3174C898 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1115: 0x3174CCA8 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1116: 0x3174D0B8 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 
     
         Allocation #1117: 0x3174D4C8 
             Allocation size: 0x400 
             Allocation traceback: 
             0xD02F4370  malloc 
             0x31791258  Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
             0x301A477C  ?? 

This example shows the allocations made by the Java process that was not freed at the point that the Java processes ended. The Java Virtual Machine itself makes a number of allocations at startup that persist for the lifetime of the JVM and are never freed. Ignore the first 1000 allocations to account for this startup allocation. Any subsequent allocation is a potential leak suspect.