分析AIX上的native内存泄露

最新推荐文章于 2023-07-03 16:58:39 发布

iteye_2535

最新推荐文章于 2023-07-03 16:58:39 发布

阅读量196

点赞数

CC 4.0 BY-SA版权

分类专栏： AIX 文章标签： AIX Java IBM JVM

本文链接：https://blog.youkuaiyun.com/iteye_2535/article/details/81889253

AIX 专栏收录该内容

95 篇文章

订阅专栏

本文介绍如何使用AIX内置的debug malloc工具来跟踪和诊断Java进程中的原生内存泄漏问题。通过设置特定的环境变量，可以激活内存分配追踪，并将详细的分配报告输出到日志文件中。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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:

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.
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.