native内存泄漏分析

最新推荐文章于 2024-03-21 17:10:34 发布

aa787282301

最新推荐文章于 2024-03-21 17:10:34 发布

阅读量4.3k

点赞数 2

分类专栏：安卓系统安卓应用 c/c++ 文章标签： android 内存泄漏

本文链接：https://blog.csdn.net/aa787282301/article/details/106629388

版权

安卓系统同时被 3 个专栏收录

52 篇文章 9 订阅

订阅专栏

安卓应用

16 篇文章 0 订阅

订阅专栏

c/c++

16 篇文章 0 订阅

订阅专栏

一.摘要

我们在分析内存泄漏时java内存泄漏我们可以集成LeakCanary来进行监控，出现问题时会打印出泄漏时的引用关系，那么我们native内存泄漏时如何分析呢？native内存泄漏我们可以通过malloc_debug工具来进行监控，详细的介绍请参考：

https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md

二.如何使用

默认情况下高通的手机已经包含了malloc_debug的代码，具体路径在：bionic/libc/malloc_debug/，下边介绍使用方法：

1.使用dumpsys meminfo --unreachable分析

1.1设置你要监控的进程：

adb shell setprop wrap.<APP>  '"LIBC_DEBUG_MALLOC_OPTIONS=backtrace"'

例如：

adb shell setprop wrap.com.smartisanos.security '"LIBC_DEBUG_MALLOC_OPTIONS=backtrace"'

adb shell am force-stop com.smartisanos.security

1.2重启进程：

设置完属性后需要重启进程，我们先杀死进程adb shell am force-stop <APP>

如果之前的设置正常，进程重启后你会发现你进程的父进程并不是zygote64，而是：

sh -c LIBC_DEBUG_MALLOC_OPTIONS=backtrace /system/bin/app_process64 /system/bin --application '--nice-name=com.smartisanos.security' com.android.internal.os.WrapperInit 35 28 'android.app.ActivityThread' '0'

这就说明我们设置好了

1.3不断复现你的问题并且抓取分配内存的调用栈：adb shell dumpsys meminfo --unreachable pid | tee app_size.txt

1.4对比你APP 不同native size产生的日志问题，寻找问题

例如:

com.smartisanos.security APP Native Heap: 66696byte 时有如下栈信息：

 Unreachable memory

  65376 bytes in 1349 unreachable allocations

  ABI: 'arm64'



  48 bytes unreachable at 75aa29e0b0

   and 62832 similar unreachable bytes in 1309 allocations

   referencing 1248 unreachable bytes in 26 allocations

   first 32 bytes of contents:

   75aa29e0b0: 18 67 43 4d 76 00 00 00 00 00 00 00 00 00 00 00 .gCMv...........

   75aa29e0c0: 00 00 00 00 00 00 00 00 b0 90 fa ad 75 00 00 00 ............u...

          #00  pc 000000000006a4f8  /system/lib64/libc++.so (operator new(unsigned long)+32)

          #01  pc 000000000007062c  /system/lib64/libhwui.so

          #02  pc 0000000000068818  /system/lib64/libhwui.so

          #03  pc 000000000006c404  /system/lib64/libhwui.so

          #04  pc 0000000000075a84  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+340)

          #05  pc 00000000000114e8  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+280)

          #06  pc 00000000000ad7ec  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140)

          #07  pc 000000000006827c  /system/lib64/libc.so

          #08  pc 000000000001f550  /system/lib64/libc.so

          #09  pc 0000000000000000  <unknown>

com.smartisanos.security APP Native Heap: 66696byte 时有如下栈信息：

Unreachable memory

  271152 bytes in 5638 unreachable allocations

  ABI: 'arm64'



  48 bytes unreachable at 75a70be430

   and 261408 similar unreachable bytes in 5446 allocations

   referencing 9168 unreachable bytes in 191 allocations

   first 32 bytes of contents:

   75a70be430: 18 67 43 4d 76 00 00 00 00 00 00 00 00 00 00 00 .gCMv...........

   75a70be440: 00 00 00 00 00 00 00 00 b0 90 fa ad 75 00 00 00 ............u...

          #00  pc 000000000006a4f8  /system/lib64/libc++.so (operator new(unsigned long)+32)

          #01  pc 000000000007062c  /system/lib64/libhwui.so

          #02  pc 0000000000068818  /system/lib64/libhwui.so

          #03  pc 000000000006c404  /system/lib64/libhwui.so

          #04  pc 0000000000075a84  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+340)

          #05  pc 00000000000114e8  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+280)

          #06  pc 00000000000ad7ec  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140)

          #07  pc 000000000006827c  /system/lib64/libc.so

          #08  pc 000000000001f550  /system/lib64/libc.so

          #09  pc 0000000000000000  <unknown>

我们发现这个栈是一样的，但是占用的内存越来越大，那么我们直接去这个栈里排查是哪里创建了内存，解析了so得到的行号如下：

Stack Trace:
  RELADDR           FUNCTION                                                                                                                                                                                       FILE:LINE
  000000000006a4f8  operator new(unsigned long)+32                                                                                                                                                                 external/libcxxabi/src/cxa_new_delete.cpp:46
  000000000007062c  android::uirenderer::renderthread::RenderMonitor::addFrame(android::uirenderer::FrameInfo&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)+456  frameworks/base/libs/hwui/renderthread/RenderMonitor.cpp:116
  0000000000068818  android::uirenderer::renderthread::CanvasContext::draw()+616                                                                                                                                   frameworks/base/libs/hwui/renderthread/CanvasContext.cpp:489
  000000000006c404  android::uirenderer::renderthread::DrawFrameTask::run()+324                                                                                                                                    frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp:114
  0000000000075a84  android::uirenderer::renderthread::RenderThread::threadLoop()+340                                                                                                                              frameworks/base/libs/hwui/renderthread/RenderThread.cpp:376
  00000000000114e8  android::Thread::_threadLoop(void*)+280                                                                                                                                                        system/core/libutils/include/utils/StrongPointer.h:?
  00000000000ad7ec  android::AndroidRuntime::javaThreadShell(void*)+140                                                                                                                                            frameworks/base/core/jni/AndroidRuntime.cpp:1256
  000000000006827c  __pthread_start(void*)+36                                                                                                                                                                      bionic/libc/bionic/pthread_create.cpp:226
  000000000001f550  __start_thread+68                                                                                                                                                                              bionic/libc/bionic/clone.cpp:47

我们可以发现这个内存是在RenderMonitor.cpp的116行申请的，那么我们看下对应的代码：

这里创建了一个MonitorTask对象，我们可以猜到这个对象估计是没有释放，那么我们找找它被释放的地方，我们发现这个对象每次执行完才会被delete：

我们继续找找如果task没有被执行呢？我们看到如下代码：

如果mMonitorTaskQueued为true，mAnimatorTaskQueued为true的时候，那么这个task就不会被delete了，到这里我们也就找到了泄漏的原因，因为这里不符合条件导致task永远不会被delete，那么我们做如下修改：

当不符合条件的时候delete task就好了

2.使用native_heapdump_viewer.py分析

有时候我们用dumpsys meminfo --unreachable打印出来的调用栈并没有什么用，即使内存泄漏了，这里显示的内存大小还是差不多的，那么我们就得用native_heapdump_viewer来分析了，使用方法如下：

1.1复现问题多次dump native内存信息：

adb shell am dumpheap -n 6813 /data/local/tmp/heap_6813.txt // 6813是你进程的pid

1.2解析内存信息：

native_heapdump_viewer.py --symbols /home/pzc/sd/log/giant/417189/6-10/symbols ./heap_6813_109444.txt > heap_109444.txt // symbols一定要对应你的rom

1.3对比解析出来的内存信息：

例如我的两次解析结果对比，com.smartisanos.security native size为：115588byte时的信息：

15241187  33.27%  33.27%     6038   7c73b6e550 /system/lib64/libc.so __start_thread bionic/libc/bionic/clone.cpp:47
 15241187  33.27% 100.00%     6038     7c73bb727c /system/lib64/libc.so __pthread_start(void*) bionic/libc/bionic/pthread_create.cpp:226
 15141747  33.05%  99.35%     4784       7c744fd7ec /system/lib64/libandroid_runtime.so android::AndroidRuntime::javaThreadShell(void*) frameworks/base/core/jni/AndroidRuntime.cpp:1256
 15141747  33.05% 100.00%     4784         7c732e04e8 /system/lib64/libutils.so android::Thread::_threadLoop(void*) system/core/libutils/include/utils/StrongPointer.h:?
 15107271  32.97%  99.77%     4672           7c761e7ab8 /system/lib64/libhwui.so android::uirenderer::renderthread::RenderThread::threadLoop() frameworks/base/libs/hwui/renderthread/RenderThread.cpp:376
 14977578  32.69%  99.14%     3981             7c761e6ca0 /system/lib64/libhwui.so android::uirenderer::renderthread::SignalingRenderTask::run() frameworks/base/libs/hwui/renderthread/RenderTask.cpp:27
 14977578  32.69% 100.00%     3981               7c761e692c /system/lib64/libhwui.so android::uirenderer::renderthread::MethodInvokeRenderTask::run() frameworks/base/libs/hwui/renderthread/RenderTask.h:85
  8978727  19.60%  59.95%     2262                 7c761e551c /system/lib64/libhwui.so android::uirenderer::renderthread::Bridge_dumpProfileInfo(android::uirenderer::renderthread::dumpProfileInfoArgs*) frameworks/base/libs/hwui/renderthread/RenderProxy.cpp:427
  8441856  18.43%  94.02%     2061                   7c76202b6c /system/lib64/libhwui.so android::uirenderer::FrameInfoVisualizer::dumpData(int) frameworks/base/libs/hwui/FrameInfoVisualizer.cpp:249
  8441856  18.43% 100.00%     2061                     7c73bb26cc /system/lib64/libc.so fwrite bionic/libc/upstream-openbsd/lib/libc/stdio/fwrite.c:83
  8441856  18.43% 100.00%     2061                       7c73bb2198 /system/lib64/libc.so __sfvwrite bionic/libc/upstream-openbsd/lib/libc/stdio/fvwrite.c:60
  8441856  18.43% 100.00%     2061                         7c73bb46e8 /system/lib64/libc.so __swsetup bionic/libc/upstream-openbsd/lib/libc/stdio/wsetup.c:73
  8441856  18.43% 100.00%     2061                           7c73bb2a64 /system/lib64/libc.so __smakebuf bionic/libc/upstream-openbsd/lib/libc/stdio/makebuf.c:62

com.smartisanos.security native size为：130088byte时的信息：

 28115314  48.67%  48.67%     9142   7c73b6e550 /system/lib64/libc.so __start_thread bionic/libc/bionic/clone.cpp:47
 28115314  48.67% 100.00%     9142     7c73bb727c /system/lib64/libc.so __pthread_start(void*) bionic/libc/bionic/pthread_create.cpp:226
 28012378  48.50%  99.63%     7870       7c744fd7ec /system/lib64/libandroid_runtime.so android::AndroidRuntime::javaThreadShell(void*) frameworks/base/core/jni/AndroidRuntime.cpp:1256
 28012378  48.50% 100.00%     7870         7c732e04e8 /system/lib64/libutils.so android::Thread::_threadLoop(void*) system/core/libutils/include/utils/StrongPointer.h:?
 27976768  48.43%  99.87%     7750           7c761e7ab8 /system/lib64/libhwui.so android::uirenderer::renderthread::RenderThread::threadLoop() frameworks/base/libs/hwui/renderthread/RenderThread.cpp:376
 27850347  48.21%  99.55%     7176             7c761e6ca0 /system/lib64/libhwui.so android::uirenderer::renderthread::SignalingRenderTask::run() frameworks/base/libs/hwui/renderthread/RenderTask.cpp:27
 27850347  48.21% 100.00%     7176               7c761e692c /system/lib64/libhwui.so android::uirenderer::renderthread::MethodInvokeRenderTask::run() frameworks/base/libs/hwui/renderthread/RenderTask.h:85
 16669534  28.86%  59.85%     4204                 7c761e551c /system/lib64/libhwui.so android::uirenderer::renderthread::Bridge_dumpProfileInfo(android::uirenderer::renderthread::dumpProfileInfoArgs*) frameworks/base/libs/hwui/renderthread/RenderProxy.cpp:427
 15638528  27.07%  93.82%     3818                   7c76202b6c /system/lib64/libhwui.so android::uirenderer::FrameInfoVisualizer::dumpData(int) frameworks/base/libs/hwui/FrameInfoVisualizer.cpp:249
 15638528  27.07% 100.00%     3818                     7c73bb26cc /system/lib64/libc.so fwrite bionic/libc/upstream-openbsd/lib/libc/stdio/fwrite.c:83
 15638528  27.07% 100.00%     3818                       7c73bb2198 /system/lib64/libc.so __sfvwrite bionic/libc/upstream-openbsd/lib/libc/stdio/fvwrite.c:60
 15638528  27.07% 100.00%     3818                         7c73bb46e8 /system/lib64/libc.so __swsetup bionic/libc/upstream-openbsd/lib/libc/stdio/wsetup.c:73
 15638528  27.07% 100.00%     3818                           7c73bb2a64 /system/lib64/libc.so __smakebuf bionic/libc/upstream-openbsd/lib/libc/stdio/makebuf.c:62

我们发现这个栈申请的内存越来越大，然后我们就去排查这个栈的代码，我们发现最好malloc是从

FrameInfoVisualizer.cpp:249这里开始的，这里申请了内存但是并没有释放，这里也没有fclose(file);

查了一下fprintf的资料，大概意思是：

fprintf：写入指定的流（这里会创建内存）

dprintf：写入指定的文件描述符（这个看上去并不会创建内存，而是直接写到fd里）

对比了下Q上的代码发现google也发现了这里有问题，并做了修改：

commit 5a44b4ff74fa7b27963c22249c815aef6225cb8d
Author: John Reck <jreck@google.com>
Date:   Mon Nov 13 11:32:39 2017 -0800

    Fix leak of FILE* in dumping
    
    Avoid fdopen as fclose, which frees the FILE*, will close
    the FD which we don't want. Just normalize on dprintf instead,
    and we can add buffering if it turns out to matter at some point
    
    Test: ran 'dumpsys gfxinfo framestats' in a loop while observing PSS
    Change-Id: I7808753641aa1055cfdf570c3e017017f11f1dee

感兴趣的同学可以再自行研究一下fprintf和dprintf的区别，这里就不继续介绍了

出现问题的原因：

正常用户不会遇到这个问题，这个只有在dumpsys gfxinfo APP的时候会走到，我们性能监控的工具刚好每隔几秒钟会去dumpsys一次，然后就会一直泄漏，修复方案：

https://android.googlesource.com/platform/frameworks/base/+/47f5c3a234c5c201ef640489af3ff25b5eec6652

三.总结

分析内存泄漏要是没有掌握好调试工具，犹如大海捞针，分析异常的困难，掌握了malloc_debug的使用方法，可以让大家分析native内存泄漏问题的效率也大大的提升～

aa787282301

关注

2
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
native内存泄漏分析

一.摘要我们在分析内存泄漏时java内存泄漏我们可以集成LeakCanary来进行监控，出现问题时会打印出泄漏时的引用关系，那么我们native内存泄漏时如何分析呢？native内存泄漏我们可以通过malloc_debug工具来进行监控，详细的介绍请参考：https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md二.如何使用默认情况下高通的手机已经包含了mal...
复制链接

扫一扫