一次Android平台native heap内存泄露的追查过程

最新推荐文章于 2025-09-30 07:20:24 发布
原创 最新推荐文章于 2025-09-30 07:20:24 发布 · 6.8k 阅读 · 11 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Android #heapsnap #内存泄露 #leak

本文记录了一次解决Android平台nativeheap内存泄露的过程。通过修改libcdebug并利用heapsnap工具，最终定位并修复了两个主要的内存泄露点。

一次过程Android平台native heap内存泄露的追查过程

前段时间有个客户报了个问题：他们的一个视频播放app在我们的Android 6.0 SDK上出现内存泄露，我用showmap查了下，该app在长时间播放视频过程中出现native heap内存的持续泄露。

原以为只要把libc debug开关打开了，就能很容易查出问题点，却没想到碰到了一些意想不到的情况。

libc debug开关使能之后，在我们的Android6.0 SDK上执行所有命令及程序都会异常崩溃，系统跑不起来了

是的，通过”setprop libc.debug.malloc 1”使能libc debug后，所有命令都跑不了了，客户的app也跑不了了，出现的Fatal信息如下： 

215 F DEBUG   : ABI: 'arm'
215 F DEBUG   : pid: 893, tid: 893, name: iptables  >>> /system/bin/iptables <<<
215 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7
614 W NativeCrashListener: Couldn't find ProcessRecord for pid 893
215 F DEBUG   :     r0 ffffffff  r1 0000000d  r2 be97e1a4  r3 00000000
215 E DEBUG   : AM write failed: Broken pipe
215 F DEBUG   :     r4 be97e1a4  r5 0000000d  r6 be97e298  r7 00000000
215 F DEBUG   :     r8 be97e298  r9 00000084  sl b6ed5bbc  fp 00000000
215 F DEBUG   :     ip b6ee606c  sp be97e178  lr b6ecf791  pc b6ecfca2  cpsr 200e0030
215 F DEBUG   : 
215 F DEBUG   : backtrace:
215 F DEBUG   :     #00 pc 00077ca2  /system/lib/libc++.so
215 F DEBUG   :     #01 pc 0007778d  /system/lib/libc++.so
215 F DEBUG   :     #02 pc 0007742d  /system/lib/libc++.so
215 F DEBUG   :     #03 pc 00048a3f  /system/lib/libc++.so (__gxx_personality_v0+290)
215 F DEBUG   :     #04 pc 0001e384  /system/bin/iptables (__gnu_Unwind_Backtrace+160)
215 F DEBUG   :     #05 pc 0001ecb4  /system/bin/iptables (___Unwind_Backtrace+20)

异常发生在libc++库中，头大，查了半天没找到原因。

试用了下valgrind，发现速度奇慢，且无法用在客户app上，用valgrind加载其它系统自带的app也是跑不起来，果断放弃。

还是想办法把Android自带的libc debug用起来。正向查不出来，那就曲线救国吧。

我修改Android5.1 SDK上面的libc++源码，添加必要函数后编译完成，替换掉样机上原来的libc++.so（样机上跑的是Android6.0系统），居然能工作正常，而且打开libc debug开关后，执行命令也不会崩溃了。

使能libc debug后，打开app，结果又出状况了…

libc debug使能后，客户app无法工作了

在没有打开libc debug时候，客户的app是能正常工作的，但通过以下命令使能libc debug之后:

setprop libc.debug.malloc 1
stop
start

然后打开客户app，一播放视频就会异常退出，异常LOG如下：

ABI: 'arm'
pid: 4011, tid: 4104, name: AsyncTask #1  >>> com.hikvision.stabilitytesttool <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x59a70ecf
    r0 00000001  r1 00004080  r2 59a70ecf  r3 00000008
    r4 00004080  r5 9edf3b60  r6 00000080  r7 00000000
    r8 9edf361c  r9 9edf36e0  sl 80000000  fp 00000005
    ip 9f488158  sp 9edf34f0  lr 9f651971  pc 9f6514d8  cpsr 240b1c30

backtrace:
    #00 pc 0027e4d8  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so
    #01 pc 0027e96d  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so
    #02 pc 0027eb61  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so
    #03 pc 002722d5  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so
    #04 pc 00008a03  /system/lib/libc_malloc_debug_leak.so (_Unwind_Backtrace+130)
    #05 pc 000060ef  /system/lib/libc_malloc_debug_leak.so
    #06 pc 00006b69  /system/lib/libc_malloc_debug_leak.so (leak_malloc+84)
    #07 pc 00272851  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so (_Znwj+12)
    #08 pc 000b51bf  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so (_ZN9CRenderer16InitVideoDisplayEi+102)
    #09 pc 000b4d61  /data/app/com.hikvision.stabilitytesttool-1/lib/arm/libPlayCtrl.so (_ZN9CRenderer14SetVideoWindowEPvii+122)

因为打开了libc debug，因此在malloc时候会保存内存分配的调用路径，从上面异常backtrace可以看到在获得该调用路径时候崩溃了。崩溃点发生在客户的库文件中。

由于没有客户app源码，无法正向去查这个异常崩溃问题，所以，依然走曲线救国的道路…

我修改libc，在反查调用路径时候，把客户app中会导致异常的线程都过滤掉，之后，客户app终于能够工作了 ^_^

使用heapsnap工具获得heap的backtrace信息

通过前面的更改，终于能用libc debug了，接下来就是用heapsnap工具抓取客户app的heap详细信息了。
heapsnap工具可以参考这篇：《HeapSnap工具原理及其应用》
以查明内存泄露的地方，很快查到了两个异常的内存泄露点：

size       12, dup 214822
....
size       12, dup 53687, 0xb4ce3e20, 0xb6d26fa8, 0xb4bcdb8a, 0xb4bbf944, 0xb4bc78e0, 0xb4ba2a96, 0xb4acb512, 0xb49732f4, 0xb6e2770c, 0xb6e27780, 0xb6bb4aee, 0xb6bad77a, 0xb6bb2e8c, 0xb6bc3cf2, 0xb5c71588, 0xb5c70200, 0xb5c73516, 0xb5bf6e1c, 0xb5bf6c84, 0xb5bf8c4e, 0xb5bf768e, 0xb6ec8854, 0xb6cb27e6, 0xb6c8a332
          #00  pc 00006e20  /system/lib/libc_malloc_debug_leak.so (leak_malloc+83)
          #01  pc 00049fa8  /system/lib/libc++.so (operator new(unsigned int)+15)
          #02  pc 0034cb8a  /system/lib/libart.so (art::ThreadList::Register(art::Thread*)+257)
          #03  pc 0033e944  /system/lib/libart.so (art::Thread::Init(art::ThreadList*, art::JavaVMExt*, art::JNIEnvExt*)+487)
          #04  pc 003468e0  /system/lib/libart.so (art::Thread::Attach(char const*, bool, _jobject*, bool)+135)
          #05  pc 00321a96  /system/lib/libart.so (art::Runtime::AttachCurrentThread(char const*, bool, _jobject*, bool)+13)
          #06  pc 0024a512  /system/lib/libart.so
          #07  pc 000f22f4  /system/lib/libart.so
          #08  pc 0008870c  /system/lib/libandroid_runtime.so (android::JNISurfaceTextureContext::getJNIEnv(bool*)+47)
          #09  pc 00088780  /system/lib/libandroid_runtime.so (android::JNISurfaceTextureContext::onFrameAvailable(android::BufferItem const&)+11)
          #10  pc 00032aee  /system/lib/libgui.so (android::ConsumerBase::onFrameAvailable(android::BufferItem const&)+93)
          #11  pc 0002b77a  /system/lib/libgui.so (android::BufferQueue::ProxyConsumerListener::onFrameAvailable(android::BufferItem const&)+45)
          #12  pc 00030e8c  /system/lib/libgui.so (android::BufferQueueProducer::queueBuffer(int, android::IGraphicBufferProducer::QueueBufferInput const&, android::IGraphicBufferProducer::QueueBufferOutput*)+1803)
          #13  pc 00041cf2  /system/lib/libgui.so (android::Surface::queueBuffer(ANativeWindowBuffer*, int)+641)
          #14  pc 0006b588  /system/lib/libstagefright.so (android::ACodec::BaseState::onOutputBufferDrained(android::sp<android::AMessage> const&)+483)
          #15  pc 0006a200  /system/lib/libstagefright.so (android::ACodec::BaseState::onMessageReceived(android::sp<android::AMessage> const&)+619)
          #16  pc 0006d516  /system/lib/libstagefright.so (android::ACodec::ExecutingState::onMessageReceived(android::sp<android::AMessage> const&)+481)
          #17  pc 0000be1c  /system/lib/libstagefright_foundation.so (android::AHierarchicalStateMachine::handleMessage(android::sp<android::AMessage> const&)+63)
          #18  pc 0000bc84  /system/lib/libstagefright_foundation.so (android::AHandler::deliverMessage(android::sp<android::AMessage> const&)+15)
          #19  pc 0000dc4e  /system/lib/libstagefright_foundation.so (android::AMessage::deliver()+53)
          #20  pc 0000c68e  /system/lib/libstagefright_foundation.so (android::ALooper::loop()+221)
          #21  pc 00010854  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
          #22  pc 000417e6  /system/lib/libc.so
          #23  pc 00019332  /system/lib/libc.so

上述信息中，size后面数值是申请内存的大小，dup后面数值是申请的次数。
这两处泄露点都是12字节的内存泄露，其中一个申请了214822次，另一个申请了53687次。前面一处的heap信息没有输出backtrace，是因为我们修改libc把异常线程过滤掉的缘故；而后面的heap信息中就带有backtrace了。

通过解读这个backtrace，可以看到libart库中的art::ThreadList::Register函数中申请了内存，但没有释放掉。

最后

最后，修改libcxx/include/list中的remove函数，重新编译art推送到样机上，再用heapsnap抓取heap信息，前面发现的那两处heap泄露点都已经不存在。至此，内存泄露问题终于解决了。

如果没有libc debug，还有哪些方式可以查这个问题呢？

mychen
关注
内存泄漏系列专题分析之五：使用malloc_debug定位C/C++ native heap内存泄露
04-11 1726
使用Malloc Debug工具，我们关心BYTES和%TOTAL两个指标。如果这两个指标一直偏大，就标明可能存在内存泄露。
使用MemoryInfo类获取进程的Native Heap、Java Heap、Graphics Heap判断递增Native内存对象
资深全栈开发工程师
06-13 810
需要注意的是，释放Native内存对象的方法可能会因对象的类型而异。如果Native Heap的内存占用超过上一次获取的信息，就会输出日志信息，提示Native Heap的内存增加了多少，并调用getObjectSource方法来判断递增的Native内存对象的来源，再调用releaseNativeHeap方法来释放Native内存对象。通过不断地调用monitorNativeHeap方法，我们可以监控递增的Native内存对象，并判断对象的来源，从而及时采取相应的措施来释放内存，提高应用程序的性能。
native内存泄漏分析
aa787282301的博客
06-08 4964
一.摘要 我们在分析内存泄漏时java内存泄漏我们可以集成LeakCanary来进行监控，出现问题时会打印出泄漏时的引用关系，那么我们native内存泄漏时如何分析呢？native内存泄漏我们可以通过malloc_debug工具来进行监控，详细的介绍请参考： https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md 二.如何使用 默认情况下高通的手机已经包含了mal...
内存泄漏与排查流程——安卓性能优化
c_z_w的博客
01-06 951
内存泄漏可以说是安卓开发中常遇到的问题，追溯和排查其问题根源是进阶的程序猿必须具备的一项技能。小盆友今天便与大家分享一下这方面的一些见解，如有理解错误或是不同见解，可以于评论区留言我们进行讨论，如果喜欢给个赞鼓励下吧。 篇幅较长，可以通过目录寻找自己所需了解的吧 目录 1、JAVA内存解析 2、JAVA回收机制 3、四种引用 4、小结 5、安卓内存泄漏排查工具 6、内存泄漏检查与解决流程 7、...
解决移动端内存噩梦：Apache Weex Native内存管理工具全攻略
最新发布
gitblog_00247的博客
09-30 910
移动端应用频繁崩溃、卡顿、耗电量大？这些问题往往与内存泄漏（Memory Leak）密切相关。据统计，70%的移动端性能问题根源在于内存管理不当。Apache Weex作为跨平台移动开发框架，提供了一套完整的Native内存管理工具链，帮助开发者精准定位并解决内存问题。本文将从实际案例出发，详解内存泄漏的检测方法、分析工具使用及解决方案，让你的应用告别内存困扰。 ## 内存泄漏的隐形威胁 内存...
Native内存泄漏一步查
Eqiqi的博客
08-23 483
到这里，我们就能通过libmemunreachable找到泄漏的内存地址以及大小了，当然，这里的信息可能还不够，比如想获取泄漏的堆栈信息等等，这个时候就需要我们去hook 一些分配函数了，比如malloc mmap等，这里我就不给出了，emmm，有机会我会填完这个坑！如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。
android native层 解析xml,Android Native内存泄漏诊断
weixin_35462155的博客
05-26 452
Android Native内存泄漏诊断1、基础诊断方法特点：操作简单，但只能判断是否有泄漏，但需使用者自行判断泄漏在哪里命令行方式adb shell dumpsys meminfo vStudio.Android.Camera360 -d结果如图： Android Studio1、选中机器和进程，点击箭头所指按钮 2、点击Memory Usage 示例例如，若需检测取景页是否有内存泄漏先在首页检...
Android内存优化（二）之获取native heap文件过程
longlong2015的博客
06-01 7655
获取某个进程native heap的方法大致分为两个步骤： 1：配置两个属性，上一篇博客中有介绍，具体操作如下： adb shell stop adb shell setprop libc.debug.malloc.program app_process adb shell setprop libc.debug.malloc.options backtrace ...
Android基于perfetto分析native内存泄露 Trace
12-20
Android基于perfetto分析native内存泄露 的trace文件及traceconv.exe 原文地址 https://blog.csdn.net/CSqingchen/article/details/128382445
内存泄漏系列专题分析之五：使用 malloc_debug 定位 C/C++ native heap 内存泄漏
wangjinjin180的博客
06-17 838
是一种基于 malloc 实现的调试工具，广泛用于检测 C/C++ 程序中的内存分配错误与泄漏。该工具在程序运行时拦截内存分配与释放操作，追踪调用栈，检测未释放内存。支持详细报告，包含泄漏内存大小、分配位置、调用链。malloc_debug 是定位 C/C++ native heap 内存泄漏的强力工具，适合深入系统调试。掌握其使用方法能有效发现难定位的内存问题，提升程序稳定性。结合其他内存工具，形成完善的内存管理体系，确保高质量软件交付。
native_heapdump_viewer.py
07-16
1.打开Android调试开关(需要userdebug版本) setenforce 0 setprop libc.debug.malloc 1 setprop libc.debug.malloc.options backtrace stop;start 2.获取进程pdi ps -ef | grep "app or service" 3.抓取步骤2进程的...
内存泄漏调试-调Native Heap
AKeywordSE的专栏
07-09 1187
$ adb shell setprop libc.debug.malloc 1   $ adb shell stop   $ adb shell start Open C:\Users\ian\.android\ddms.cfg Add a line "native=true" 打开DDMS，点Native Heap标签，就可以Snapshot了
android native内存泄漏检测原理
编程菜鸟进阶之路
04-16 1156
android native内存泄漏检测原理初始化释放和分配函数的处理获取泄漏信息header的作用内存泄漏显示 本文根据Android 8.1编写，代码路径在bionic目录下。 初始化 每个进程都会执行函数malloc_init_impl初始化内存分配框架。 初始化函数 void* malloc_impl_handle = dlopen(DEBUG_SHARED_LIB, RTLD_NOW |...
使用DDMS中的native heap 检查Android native 内存泄露
iteye_20059的博客
05-30 964
一、 手机端准备工作 1、 安装库文件         所有的  native  内存分配函数  ( malloc ,  calloc , etc.)  都在  Android 的 libc   库中。为了跟踪堆内存的分配，需要使用这个库的特别版本，可以将每次内存开销记录下来。   这些特殊版本的   ...
定位分析Android Native 内存泄漏
javashu2012的专栏
02-18 1091
前提條件 Android版本為8.0以上 環境配置 cd到/src/main目錄下，新建shell目錄，同時shell目錄下配置與libs目錄下相同平台的目錄，如下app下的層級結構，可看到shell/lib下具有與libs下相同的平台目錄結構 ── AndroidManifest.xml ├── java ├── libs │ ├── arm64-v8a │ └── armeabi...
Android 内存笔记
Ritter Liu的专栏
12-25 5215
Avoiding memory leaks Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to ach
JVM的Heap Memory和Native Memory
热门推荐
Venus专栏
04-20 1万+
JVM管理的内存可以总体划分为两部分：Heap Memory和Native Memory。前者我们比较熟悉，是供Java应用程序使用的；后者也称为C-Heap，是供JVM自身进程使用的。Heap Memory及其内部各组成的大小可以通过JVM的一系列命令行参数来控制，在此不赘述。Native Memory没有相应的参数来控制大小，其大小依赖于操作系统进程的最大值（对于32位系统就是3~4G，各种系统
Android native heap内存占用分析
SurpriseDPD的博客
04-17 2571
参考文章： Android Native层（C++）内存泄露诊断 2. 单抓native heap dump 先设置属性： 然后启动app并使用，然后抓dump信息： 3. 用native_heapdump_viewer.py分析 工具获取方法：  将native_heap.txt文件上传到编译平台，通过native_heapdump_viewer.py脚本解析该文件。这个脚本的大致原理呢其实就是利用addr2line将Sysmbol表与我们dunp下来的地址进行map比对，同时呢计算出每个so库所分配的内
android内存native区,Android内存优化（二）之获取native heap文件过程
weixin_28878117的博客
05-30 1206
获取某个进程native heap的方法大体分为两个步骤：1：配置两个属性，上一篇博客中有介绍，具体操做以下：adb shell stopadb shell setprop libc.debug.malloc.program app_processadb shell setprop libc.debug.malloc.options backtraceadb shell start2：shell命...
Java Heap: Native Heap 内存占用一直变化
08-29
Java Heap和Native Heap内存占用一直变化的原因主要有以下几点： ### Java Heap内存占用变化原因 - **对象创建与销毁**：在应用运行过程中，会不断地创建新的Java对象，这些对象会被分配到Java Heap中，从而使Java Heap的内存占用增加。当这些对象不再被引用时，垃圾回收机制会将它们标记为可回收对象，并在合适的时机进行回收，此时Java Heap的内存占用就会减少。例如，在一个循环中不断创建新的字符串对象，Java Heap的内存占用会持续上升；当循环结束且这些对象不再被引用后，垃圾回收器会回收这些对象，内存占用下降[^1]。 ```java for (int i = 0; i < 1000; i++) { String str = new String("test"); // 更多代码 } // 一段时间后，垃圾回收可能会回收这些字符串对象 ``` - **垃圾回收机制**：Java的垃圾回收机制是自动进行的，但它的触发时机和执行效率会影响Java Heap的内存占用。当垃圾回收器启动时，会暂停应用的部分线程，对Java Heap中的对象进行标记和清理。不同的垃圾回收算法和策略会导致不同的内存占用变化模式。例如，当Java Heap的使用量达到一定阈值时，会触发垃圾回收，回收后内存占用会下降；如果垃圾回收不及时，内存占用会持续升高[^1]。 - **业务逻辑需求**：应用的业务逻辑决定了对象的创建和使用频率。例如，在一个图片处理应用中，当用户打开一张大图片时，应用会创建大量的图像对象，Java Heap的内存占用会迅速增加；当图片处理完成或关闭图片时，这些对象可能会被释放，内存占用减少。 ### Native Heap内存占用变化原因 - **本地库的使用**：许多Android应用会使用本地库（如C、C++库）来实现一些高性能的功能。这些本地库在运行时会在Native Heap中分配内存。当本地库加载、执行操作或释放资源时，Native Heap的内存占用会相应地发生变化。例如，一个使用OpenCV库进行图像识别的应用，在加载OpenCV库和处理图像时，Native Heap的内存占用会增加；处理完成后，释放相关资源，内存占用减少[^1]。 - **内存泄漏**：由于Native Heap没有自动的垃圾回收机制，内存泄漏在Native Heap中更容易发生。如果在本地代码中分配了内存但没有正确释放，随着应用的运行，Native Heap的内存占用会不断增加。例如，在C++代码中使用`new`分配了内存，但忘记使用`delete`释放，会导致内存泄漏，使Native Heap的内存占用持续上升[^1]。 ```cpp void memoryLeakFunction() { int* ptr = new int[100]; // 忘记释放内存 } ``` - **系统资源竞争**：Android系统中的多个应用和进程会共享系统的内存资源。当系统内存紧张时，操作系统可能会对应用的Native Heap内存进行调整，导致应用的Native Heap内存占用发生变化。例如，当其他应用占用大量内存时，当前应用的Native Heap可能会被压缩，内存占用减少。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值