`
netcome
  • 浏览: 482308 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

分析linux上的native内存泄露

阅读更多

Running native profiling on Linux

Read the information provided

Introduction

Several memory profilers are available for the Linux operating system, which fit into the following categories:

Preprocessor level
These profilers require a header to be compiled with the source under test. You can recompile your own JNI libraries with one of these tools to track a native memory leak in your code. Unless you have the source code for Java itself, this recompilation cannot find a leak in the JVM. Compiling this kind of tool into a large project like a JVM would almost certainly be difficult and time-consuming. Dmalloc is an example of this kind of tool.
Linker level
These profilers require the binaries under test to be relinked with a debugging library. You can relink individual JNI libraries but it is not recommended for entire Java runtimes because the runtime vendor is unlikely to support the use of modified binaries. Ccmalloc is an example of this kind of tool.
Runtime-linker level
These profilers use the LD_PRELOAD environment variable to preload a library that replaces the standard memory routines with instrumented versions. These profilers do not require recompilation or relinking of source code but many of them do not work well with Java runtimes. A Java runtime is a complicated system that can use memory and threads in unusual ways. It is worth experimenting with a few to see if they work in your scenario. NJAMD is an example of this kind of tool.
Emulator-based
Valgrind is the only example of this type of memory debugger. It emulates the underlying processor in a similar way to the way that a Java runtime emulates the Java virtual machine. It is possible to run Java under Valgrind, but the heavy performance impact (25 - 50 times slower) makes it very difficult to run large, complicated Java applications in this manner. Valgrind is currently available on Linux x86, AMD64, PPC32, and PPC64. If you are intend to use Valgrind, try to narrow down the problem to the smallest possible testcase you can before using it.

For simple scenarios that can tolerate the performance overhead, Valgrind is the most simple and user-friendly of the available free tools. Valgrind can provide a full stack trace for code paths that are leaking memory.

Running a process in Valgrind

Because Valgrind is an emulation environment, the process must be run under Valgrind, and the analysis finishes when the process ends. To use Valgrind with a process that usually runs indefinitely, you must be able to stop the process.

Some Java runtimes use thread stacks and processor registers in unusual ways. This usage can confuse some debugging tools, which expect native programs to abide by standard conventions of register use and stack structure. When using Valgrind to debug leaking JNI applications, you might see many warnings about the use of memory and some unusual thread stacks. These effects are caused by the way that the Java runtime structures its data internally and they are not a problem.

To trace the LeakyJNIApp with the Valgrind memcheck tool, use this command:

   valgrind --trace-children=yes --leak-check=full java -Djava.library.path=. com.ibm.jtc.demos.LeakyJNIApp 10 

The --trace-children=yes option makes Valgrind trace any processes that are started by the Java launcher. Some versions of the Java launcher restart themselves after setting environment variables to change behavior. If you do not specify --trace-children, you might not trace the Java runtime.

The --leak-check=full option requests that full stack traces of leaking areas of code are printed at the end of the run, instead of a summary of the state of the memory.

Valgrind prints many warnings and errors while the command runs, most of which are not relevant in this context. When your process ends, it prints a list of leaking call stacks in ascending order of amount of memory leaked.

This example shows the end of the summary section of the Valgrind output for LeakyJNIApp on Linux x86:

   ==20494== 8,192 bytes in 8 blocks are possibly lost in loss record 36 of 45 
    ==20494==    at 0x4024AB8: malloc (vg_replace_malloc.c:207) 
    ==20494==    by 0x460E49D: Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
    (in /home/andhall/LeakyJNIApp/libleakyjniapp.so) 
    ==20494==    by 0x535CF56: ??? 
    ==20494==    by 0x46423CB: gpProtectedRunCallInMethod 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x46441CF: signalProtectAndRunGlue 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x467E0D1: j9sig_protect 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9prt23.so) 
    ==20494==    by 0x46425FD: gpProtectAndRun 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x4642A33: gpCheckCallin 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x464184C: callStaticVoidMethod 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x80499D3: main 
    (in /usr/local/ibm-java2-i386-50/jre/bin/java) 
    ==20494== 
    ==20494== 
    ==20494== 65,536 (63,488 direct, 2,048 indirect) bytes in 62 blocks are definitely 
    lost in loss record 42 of 45 
    ==20494==    at 0x4024AB8: malloc (vg_replace_malloc.c:207) 
    ==20494==    by 0x460E49D: Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 
    (in /home/andhall/LeakyJNIApp/libleakyjniapp.so) 
    ==20494==    by 0x535CF56: ??? 
    ==20494==    by 0x46423CB: gpProtectedRunCallInMethod 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x46441CF: signalProtectAndRunGlue 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x467E0D1: j9sig_protect 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9prt23.so) 
    ==20494==    by 0x46425FD: gpProtectAndRun 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x4642A33: gpCheckCallin 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x464184C: callStaticVoidMethod 
    (in /usr/local/ibm-java2-i386-50/jre/bin/libj9vm23.so) 
    ==20494==    by 0x80499D3: main 
    (in /usr/local/ibm-java2-i386-50/jre/bin/java) 
    ==20494== 
    ==20494== LEAK SUMMARY: 
    ==20494==    definitely lost: 63,957 bytes in 69 blocks. 
    ==20494==    indirectly lost: 2,168 bytes in 12 blocks. 
    ==20494==      possibly lost: 8,600 bytes in 11 blocks. 
    ==20494==    still reachable: 5,156,340 bytes in 980 blocks. 
    ==20494==         suppressed: 0 bytes in 0 blocks. 
    ==20494== Reachable blocks (those to which a pointer was found) are not shown. 
    ==20494== To see them, rerun with: --leak-check=full --show-reachable=yes 
    

The second line of the stacks shows that the memory was leaked by the com.ibm.jtc.demos.LeakyJNIApp.nativeMethod() method.

Read the information provided

Identify the native heap leak owner


分享到:
评论

相关推荐

    内存泄露检测工具

    除了VLD,还有其他一些著名的内存泄露检测工具,如Valgrind(主要针对Linux平台),LeakSanitizer(asan,是Google开发的一个内存错误检测工具),以及一些IDE自带的内置工具,如Visual Studio的诊断工具等。...

    linux & JVM内存结构分析

    分析这些文件,我们可以获取到系统的内存使用状况,如哪些对象占用大量内存,是否存在内存泄漏,以及垃圾回收的效率等。通过理解Linux和JVM内存的运作机制,开发者可以更好地优化程序性能,避免内存问题的发生。 ...

    Java内存泄露_JVM监控工具介绍

    "Java内存泄露_JVM监控工具介绍" Java内存泄露是Java开发中常见的一种问题,发生内存泄露可能会导致Java应用程序崩溃或性能下降。在Java中,内存泄露的原因非常多样,例如,静态变量、循环引用、数据库连接池、...

    android项目内存泄露排查实用.pdf

    Android项目内存泄露排查实用 本文主要讲述了 Android 项目...本文主要讲述了 Android 项目中内存泄露的排查和解决方法,包括使用 DDMS 和 MAT 工具来检测内存泄露,分析问题的根源,并采取相应的解决方法来解决问题。

    抓取memory的shell(native和hprof)

    本文将深入探讨如何使用shell命令在Linux环境中捕获和分析内存状态,主要关注两种不同的内存快照格式:native内存和HProf文件。 首先,让我们了解什么是native内存。在Linux系统中,native内存通常指的是C/C++代码...

    android项目内存泄露排查[收集].pdf

    通过adb shell dumpsys meminfo命令查看,发现在Android 2.3.5上native空间被大量占用,原因是自定义字体(arial.ttf)的加载过程中,JNI调用C代码时出现了native内存泄露。这个问题在Android 4.0.3上得到了修复,...

    apache服务器出现内存溢出的解决方法.doc

    - 如果应用程序中存在内存泄漏,则需要修复代码中的问题。 2. **PermGen space** - **原因**:永久代(PermGen)用于存储类定义、常量池等信息。当永久代空间不足时,会抛出这种异常。这通常是由于加载了过多的类...

    memtester-4.5.1( Linux & Android 内存压力测试,带Android.mk)

    6. **内存压力测试**:这种测试方法通过模拟高负载情况,检查系统在极端条件下的行为,找出内存泄漏、性能瓶颈等问题。 7. **编译与部署**:在Linux或Android环境下,用户需要熟悉make工具和Android NDK,以编译...

    Unity3D调用Native OpenGL渲染方式

    4. **资源管理**:正确地创建、销毁和管理OpenGL资源,避免内存泄漏。 通过Unity3D调用Native OpenGL渲染,开发者可以深入到图形编程的底层,实现更复杂、高性能的视觉效果,同时保持Unity3D的跨平台优势。这对于...

    Android Native Service

    2. **内存管理**:C/C++代码中需要手动管理内存,避免内存泄漏。 3. **线程调度**:合理安排线程优先级,避免阻塞主线程。 4. **性能监控**:使用性能分析工具,如`systrace`和`NDK Profiler`,来检测和优化代码...

    async-profiler-1.8.1-linux-x64.tar.gz

    3. 跟踪内存分配:追踪内存分配情况,发现内存泄漏或不必要的对象创建,提高内存使用效率。 4. 监控系统调用:观察频繁的系统调用,减少I/O操作,提升系统性能。 五、总结 async-profiler是Java性能分析的利器,它...

    valgrind for NDK (ANDROID NDK内存检测工具)

    `Valgrind` 是一个开源的内存错误检测和性能分析工具,它能够帮助开发者找出程序中的内存泄漏、未初始化的内存访问、无效的指针使用等问题。`Valgrind for NDK` 是将 `valgrind` 工具移植到Android环境,特别是针对...

    Android内存检测

    此外,`dumpsys meminfo`命令也能提供关于应用内存使用情况的详细报告,包括dalvik heap、native heap、ashmem、渲染器等不同部分的信息。 在实践中,开发者需要关注内存泄漏、内存抖动和内存碎片等常见问题。内存...

    JVM内存问题最佳实践

    #### 六、使用分析工具解决内存不足和内存泄漏错误 - **JVisualVM**:内置在JDK中,可以监控JVM状态、进行堆分析等。 - **MAT**:Eclipse项目的一部分,专门用于分析Java堆内存使用情况。 - **VisualGC**:提供图形...

    loadrunner监控linux必备插件

    1. **LR Native Linux Monitor**:这是LoadRunner自带的Linux监控插件,它能够收集CPU使用率、内存占用、磁盘I/O和网络流量等关键性能指标。在Controller中配置此插件,可以实时监控被测系统的资源消耗情况。 2. **...

    android 7.1 获取各个应用的各种内存信息的app demo

    4. **Debug.MemoryInfo**: 对于更深入的内存分析,可以使用`Debug`类的静态方法`getMemoryInfo()`,它返回一个`Debug.MemoryInfo`对象,包含了Dalvik/ART堆、Native堆、 ashmem和图形内存等的详细信息。 5. **Linux...

    内存不足OOM java.lang.OutOfMemoryError.

    - 使用内存分析工具(如VisualVM、MAT或YourKit)可以帮助诊断内存泄漏,找出长期占用内存的对象。 - 对象的生命周期管理和合理的数据结构选择也是防止内存泄漏的关键。 5. **垃圾收集与性能调优**: - 垃圾收集...

    Java Native Access JNA-4.5.0

    5. **内存管理**:JNA 提供了内存管理机制,自动处理本地分配和释放内存,避免了内存泄漏问题。 6. **结构体和联合体支持**:JNA 支持Java类映射到C语言的结构体和联合体,使得复杂数据结构的传递变得简单。 7. **...

    问题分析:java.lang.OutOfMemoryError unable to create new native thre

    【Java虚拟机内存溢出分析】:当遇到`java.lang.OutOfMemoryError: unable to create new native thread`错误时,这通常表示系统无法为新的Java线程分配足够的内存,即操作系统层面的资源耗尽,而非Java堆内存不足。...

    jprofiler_linux_8_0_7.tar.gz

    1. **增强的内存分析**:在8.0.7版本中,JProfiler对内存分析模块进行了优化,可以更准确地定位内存泄漏,同时提供了更直观的内存分配图表,帮助开发者理解内存使用模式。 2. **CPU性能优化**:针对多核处理器,...

Global site tag (gtag.js) - Google Analytics