【内存泄漏】内存泄漏及常见的内存泄漏检测工具介绍

十橙2023-12-27 10:31

内存泄漏介绍

什么是内存泄漏

内存泄漏是指程序分配了一块内存（通常是动态分配的堆内存），但在不再需要这块内存的情况下未将其释放。内存泄漏会导致程序浪费系统内存资源，持续的内存泄漏还导致系统内存的逐渐耗尽，最终导致程序或系统崩溃。

内存泄漏和常驻内存区别

常驻内存（Resident Set）是指进程在运行期间占用的内存大小，包括进程使用的代码、数据和其他资源。常驻内存是进程在运行期间一直驻留在内存中的部分，即使在进程不活动时也不会被释放。

常驻内存通常不会带来显著的负面影响。

程序与进程里的内存布局

下图是源码与 ELF（可执行可链接） 文件以及运行起来后内存布局的简易映射关系图。

程序中的初始化全局变量和局部静态变量被编译到 .data，未初始化的全局变量和局部静态变量编译后放在 .bss 段，代码主体和函数主题存放在 .text 段，ELF 文件内实际有很多段（参考《程序员的自我修养-链接，装载与库》第三章）。

当程序运行时，会将 ELF 文件加载到内存。不同的段会加载到内存布局中的不同位置，其中 heap 这部分就是程序员手动去动态申请和释放内存的部分。当程序员用 malloc 函数申请了一块内存，使用完之后却没有 free 它的时候，就会发生内存泄漏。内存泄漏得越多，进程中可以使用内存的空间就越少，时间长了就会导致系统响应慢，甚至程序崩溃。

如何"观察"内存泄漏是否发生？

在 Android 系统上通常可以用 dumpsys meminfo 命令查看进程的内存使用数据，重复 dump 后从数据的变化情况来大致判断是否有内存泄漏。

也可以借助python 或者其他一些工具将数据可视化方便查看数据变化趋势。

但这只能大致的给你展示数据变化的趋势，而非直接明白的告诉你是否发生了内存泄漏。因此我们需要更精确的工具来检测是否也有内存泄漏。

常见的内存检测工具介绍

本节我们将依次介绍 Malloc Debug, libmemunreachable, Asan, HwASan, MTE, Heapprofd, Memcheck(Valigrind)

内存泄漏检测工具(https://source.android.com/docs/core/tests/debug/native-memory?hl=zh-cn)

Malloc Debug

简介

Malloc Debug 是一种调试本机内存问题的方法。 它可以帮助检测内存损坏、内存泄漏和释放后使用问题。

Malloc Debug 通过对常规的 allocation 函数包装了一层来记录和分析内存的申请和释放。这些函数包括：malloc, free, calloc, realloc, posix_memalign, memalign, aligned_alloc, malloc_usable_size

使用方法

运行程序前的设置

shell 复制代码 
adb shell setprop libc.debug.malloc.options "\"backtrace guard leak_track backtrace_dump_on_exit backtrace_dump_prefix=/sdcard/heap"\"
adb shell setprop libc.debug.malloc.program xxx(进程名)

参数介绍：

  • backtrace: 开启堆栈记录。
  • guard: 开启内存越界检测。
  • leak_track: 程序在退出时，如有内存泄漏，而不产生abort。
  • backtrace_dump_on_exit: 程序退出时dump堆栈和内存信息。
  • backtrace_dump_prefix: dump文件存放的路径和文件名的开头字符。如本处生成的文件放在/sdcard/目录下，文件名开头为heap字样，注意指定的路径要有写权限。
  • libc.debug.malloc.program: 用于设置检测的程序，不设置则检测所有的运行的程序。

执行待测试程序

  1. 离线程序
    离线程序运行完成后会在 backtrace_dump_prefix 设定的路径下存储 dump 文件
  2. 在线程序
    需要先停掉程序所在的进程，再重启该进程才会生效。
    由于在线程序一般不会主动退出（如 camerahalserver），需要使用命令来主动触发 dump。
    命令：kill -47 xxx(进程ID)，注意多次触发新文件覆盖之前的文件。
    当你的程序有内存泄漏问题的话，输出如下报告：
shell 复制代码 
E malloc_debug: +++ memtest leaked block of size 48 at 0x7a4a6a42e0 (leak 1 of 2)
E malloc_debug: Backtrace at time of allocation:
E malloc_debug:           #00  pc 000000000004461c  /apex/com.android.runtime/lib64/bionic/libc.so (malloc+76)
E malloc_debug:           #01  pc 00000000000c83e8  /apex/com.android.runtime/lib64/bionic/libc.so (__register_atfork+40)
E malloc_debug:           #02  pc 000000000005460c  /apex/com.android.runtime/lib64/bionic/libc.so
E malloc_debug:           #03  pc 00000000000613a0  /apex/com.android.runtime/bin/linker64
E malloc_debug:           #04  pc 0000000000061144  /apex/com.android.runtime/bin/linker64
E malloc_debug:           #05  pc 0000000000061144  /apex/com.android.runtime/bin/linker64
E malloc_debug:           #06  pc 00000000000d5f14  /apex/com.android.runtime/bin/linker64
E malloc_debug:           #07  pc 00000000000d4e0c  /apex/com.android.runtime/bin/linker64
E malloc_debug:           #08  pc 0000000000064004  /apex/com.android.runtime/bin/linker64
E malloc_debug: +++ memtest leaked block of size 20 at 0x793a6ae9a0 (leak 2 of 2)
E malloc_debug: Backtrace at time of allocation:
E malloc_debug:           #00  pc 000000000004461c  /apex/com.android.runtime/lib64/bionic/libc.so (malloc+76)
E malloc_debug:           #01  pc 00000000000100b8  /data/local/tmp/memtest/memtest
E malloc_debug:           #02  pc 00000000000546e8  /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+104)
E malloc_debug: Dumping to file: /sdcard/heap.19748.exit.txt

注意报告中并不是所有的 leak 都是真正的内存泄漏，有些可能是常驻内存，开发者需要自己判断。

还需注意dump 路径要有写权限

很多时候在线运行环境下so 是无符号的程序，我们需要解析 dump 文件定位代码行号
python3 native_heapdump_viewer.py --symbols ./symboldir/ ./heap.4169.exit.txt --html > memtest4169.html

--symbols 指定的是符号库/程序的路径，子目录的路径必须要在手机上的路径一致。比如可执行程序在手机里的路径是/vendor/bin/memtest，那解释时它的带符号的程序路径上需要是 ./symboldir/vendor/bin/memtest

检测出来的并不是都是泄漏，一部分是属于常驻内存，尤其对于在线程序，我们需要将程序运行不同的次数，抓出不同的log来做对比，找出真正增长的部分。

libmemunreachable

简介

Android 的 libmemunreachable 是一个零开销 的本地内存泄漏检测器。 它会在触发内存检测的时候遍历进程内存，同时将任何不可访问的块报告为泄漏。

命令行方式使用

设置属性

shell 复制代码 
adb root
adb shell setprop libc.debug.malloc.program app_process
adb shell setprop wrap.[process] "\$\@"
adb shell setprop libc.debug.malloc.options backtrace=4

参数

  • backtrace_size 只收集泄漏指定 size 大小的 backtrace
  • backtrace_min_size=192 backtrace_max_size=320 收集泄漏 size 介于两者之间的backtrec

重启应用，执行 dumpsys -t 600 meminfo --unreachable [process].（自测没有 dump 出预期结果）。下面是一个带有内存问题的输出结果。

shell 复制代码 
 Unreachable memory
  24 bytes in 2 unreachable allocations
  ABI: 'arm64'

  24 bytes unreachable at 71d37787d0
   first 20 bytes of contents:
   71d37787d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
   71d37787e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

  24 bytes unreachable at 71d37797d0
   first 20 bytes of contents:
   71d37797d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
   71d37797e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

添加代码方式使用

官方提供4个接口来检测内存

C interface

  • bool LogUnreachableMemory(bool log_contents, size_t limit)
  • bool NoLeaks()

C++ interface

  • bool GetUnreachableMemory(UnreachableMemoryInfo& info, size_t limit = 100)
  • std::string GetUnreachableMemoryString(bool log_contents = false, size_t limit = 100)

核心函数是 GetUnreachableMemory() 其他三个函数内部都会调用此函数。

在使用添加代码的方式打印时，需要在编译代码时需要将 libmemunreachable.so 添加到动态依赖，libmemunreachable.so 文件可以在手机 /system/lib64/libmemunreachable.so 获取。

例子：

以下是一个包含内存泄漏的例子，在f 函数中申请了x, y 两块内存，在函数返回前x 被释放，y 赋值后没有被释放。

c++ 复制代码 
#include "./memunreachable.h"

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

using namespace android;

void f(void);
void f(void) {
  printf("[memtest] function f\n");
  int* x = (int*)malloc(10 * sizeof(int));
  x[0] = 0;
  int* y = (int*)malloc(5 * sizeof(int));
  y[0] = 0;
  y[1] = 1;
  y[2] = 2;
  y[3] = 3;
  y[4] = 4;
  free(x);
}

int main(void) {
  printf("[memtest] hello main\n");
  f();

  // C interface
  printf("LogUnreachableMemory()\n");
  LogUnreachableMemory(true, 100);

  return 0;
}

adb log 输出（考虑排版省去时间戳）

log 里显示有一个 20 bytes 的内存泄漏，20 正是5 个 int 的大小，对应申请但没有释放的 y 地址的内存。

shell 复制代码 
// 新建 Collection process
31232 31231 I libmemunreachable: collecting thread info for process 31231...
31232 31231 I libmemunreachable: collection thread done
// fork 进程运行 sweeping process 
31233 31233 I libmemunreachable: searching process 31231 for allocations
31233 31233 I libmemunreachable: searching done
31233 31233 I libmemunreachable: sweeping process 31231 for unreachable memory
31233 31233 I libmemunreachable: sweeping done
31233 31233 I libmemunreachable: folding related leaks
31233 31233 I libmemunreachable: folding done
// 回到 Original process 接收检测结果
31231 31231 I libmemunreachable: unreachable memory detection done
31231 31231 E libmemunreachable: 20 bytes in 1 allocation unreachable out of 1260 bytes in 7 allocations
31231 31231 E libmemunreachable:   20 bytes unreachable at 7a03454400
31231 31231 E libmemunreachable:    contents:
31231 31231 E libmemunreachable:    7a03454400: 00 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 ................
31231 31231 E libmemunreachable:    7a03454410: 04 00 00 00                                     ....
31231 31231 E libmemunreachable:           #00  pc 000000000003e238  /apex/com.android.runtime/lib64/bionic/libc.so (malloc+84)
31231 31231 E libmemunreachable:           #01  pc 00000000000100b8  /data/local/tmp/memtest/memtest_libmemunreachable
31231 31231 E libmemunreachable:           #02  pc 000000000004aa48  /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+100)

调用 bool LogUnreachableMemory(bool log_contents, size_t limit) 时，log_contents 传 true 会打印泄露地址的内容，也就是 contents 对应的两行内容。之后可以用 address2line 解析行号。

其他内存检测工具简介

ASan

  • Asan(AddressSanitizer) 适用于检测内存越界访问、缓冲区溢出、内存泄漏等问题。它是一个在编译时插入的工具；
  • 运行时有一定的性能开销（约增加两倍），代码大小和内存均有额外开销;
  • 需要重新编译程序，编译时添加 address 相关选项；
  • 可用于 linux 和 android，但在 android 上逐步被 HwASan 取代；
  • 需要刷与 ASan 兼容的 ROM；
  • 不再受支持，即使有bug 也不会修复；

HWASan

  • HWASan 利用硬件特性，适用于检测内存错误，类似于 ASan，但能够更高效地运行在一些支持硬件特性的平台上。
  • 性能开销和 Asan 接近，但内存占用更小；
  • 需要重新编译程序，编译时添加 hwaddress 相关选项
  • 仅适用于 Android 10 及更高版本，AArch64 硬件；
  • 需要刷与 HWASan 兼容的 ROM；

MTE

  • MTE(Memory Tagging Extension) 使用硬件标签来检测内存错误，主要专注于检测内存越界访问。
  • 提供了较低的性能开销，首次具备了线上部署的可能。
  • 无需重新构建代码来检测堆错误（但需要重新构建代码来检测堆栈错误）
  • Android 系统在 Arm v9 上开始支持，仅适用于64位应用/程序；

Heapprofd

  • Heapprofd 是一个跟踪给定时间段内 Android 进程的堆分配和释放的工具。
  • 可以借助 Perfetto 抓取，开发人员可以使用该工具调查内存问题（调用栈和内存分配）。

    当开启连续 dump 后，开发者可以查看程序结束前内存占用是否合理，以检查是否有潜在内存泄漏问题。或者将待测试代码循环执行，比较每执行一次代码段后内存是否有增加，一次判断是否有内存泄漏。

Valgrind 中的Memcheck

  • Memcheck 是 Valgrind 工具套件中的一个工具，用于检测 C 和 C++ 程序中的内存错误。
  • 内存问题检测比较全面，但对性能影响比较大，耗时增加10x~20x，不适用对时间敏感的程序。
  • 在 Ubuntu 上安装：sudo apt-get install valgrind

使用 memcheck 的基本方法

  • 编译程序时加上 --g 选项，编译优化选项建议选择 -O1;
  • 使用 Valgrind 命令运行程序：valgrind --leak-check=yes myprog arg1 arg2valgrind 使用 --tools 来指定 debug 工具，而 Memcheck 是默认工具，可以省略 --tools=memcheck 选项；
  • 程序运行后输出问题报告。
SHELL 复制代码 
$ valgrind --leak-check=yes ./memtest_origin 
==19517== Memcheck, a memory error detector
==19517== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19517== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==19517== Command: ./memtest_origin
==19517== 
[memtest] hello main
[memtest] function f
==19517== 
==19517== HEAP SUMMARY:
==19517==     in use at exit: 20 bytes in 1 blocks
==19517==   total heap usage: 3 allocs, 2 frees, 1,084 bytes allocated
==19517== 
==19517== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19517==    at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19517==    by 0x1086FF: f() (memtest_origin.cc:9)
==19517==    by 0x108731: main (memtest_origin.cc:16)
==19517== 
==19517== LEAK SUMMARY:
==19517==    definitely lost: 20 bytes in 1 blocks
==19517==    indirectly lost: 0 bytes in 0 blocks
==19517==      possibly lost: 0 bytes in 0 blocks
==19517==    still reachable: 0 bytes in 0 blocks
==19517==         suppressed: 0 bytes in 0 blocks
==19517== 
==19517== For counts of detected and suppressed errors, rerun with: -v
==19517== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

总结

本文我们介绍了内存泄漏的概念，malloc debug 和 libmemunreachable 的使用方法，以及一些其他内存检测工具的简介，下一篇我们将介绍 malloc debug 和 libmemunreachable 的工作原理。

参考链接

  1. 【内存】Android C/C++ 内存泄漏分析 unreachable
  2. 调试本地内存使用 | Android 开源项目 | Android Open Source Project
  3. 调试和减少内存错误 | Android NDK | Android Developers (google.cn)
  4. Malloc Debug (googlesource.com)
  5. Malloc Hooks (googlesource.com)
  6. libmemunreachable (googlesource.com)
  7. Memcheck: a memory error detector
  8. Heap profiler - Perfetto Tracing Docs
相关推荐
捕鲸叉3 小时前
创建线程时传递参数给线程
开发语言·c++·算法
A charmer3 小时前
【C++】vector 类深度解析：探索动态数组的奥秘
开发语言·c++·算法
Peter_chq3 小时前
【操作系统】基于环形队列的生产消费模型
linux·c语言·开发语言·c++·后端
青花瓷5 小时前
C++__XCode工程中Debug版本库向Release版本库的切换
c++·xcode
幺零九零零6 小时前
【C++】socket套接字编程
linux·服务器·网络·c++
捕鲸叉6 小时前
MVC（Model-View-Controller）模式概述
开发语言·c++·设计模式
Dola_Pan7 小时前
C++算法和竞赛：哈希算法、动态规划DP算法、贪心算法、博弈算法
c++·算法·哈希算法
yanlou2337 小时前
KMP算法，next数组详解（c++）
开发语言·c++·kmp算法
小林熬夜学编程7 小时前
【Linux系统编程】第四十一弹---线程深度解析：从地址空间到多线程实践
linux·c语言·开发语言·c++·算法
阿洵Rain8 小时前
【C++】哈希
数据结构·c++·算法·list·哈希算法
热门推荐
01【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总02(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04【AIGC】重塑未来的科技巨轮05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06【经验分享】Ubuntu22.04安装微信(linux官方版)07基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测08Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO09RAG 实践- Ollama+RagFlow 部署本地知识库10红米手机使用google play