当前位置: 首页 > news >正文

使用AddressSanitizer搭配addr2line查找C/C++内存泄漏问题

文章目录

  • 前言
  • AddressSanitizer
  • 检测步骤
    • 泄漏发生在可执行程序本身
    • 泄漏发生在编译所需动态库中
    • 泄漏发生在自定义加载的动态库中
      • unknown module
      • maps
      • 具体操作
  • 总结

前言

指针是C/C++程序中的利器,同时也引入了风险,现代C++中增加了智能指针来降低使用“裸”指针带来的风险,但是智能指针不是一颗银弹,它不能解决所有的指针问题,内存泄漏在C/C++程序开发中依旧是值得注意的,学会合理、合适的方法来查找内存泄漏问题也是一项有用的技能。

通常内存泄漏问题会在开发到一定程度时集中检查,一些检测方法长时间不去使用难免会忘记,所以本文记录一种自己常用的检测方法,方便日后查阅。

AddressSanitizer

AddressSanitizer 是什么东西呢?从名字上直接翻译叫“地址消毒剂”,其实就是用来检查地址问题的。

它是一款地址问题检测工具,简称 ASAN,开源项目主地址为 google/sanitizers,是众多检测工具AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer 中的一款,功能非常强大,可以检测出栈上缓冲区溢出、堆上缓冲区溢出、引用已释放内存、内存泄漏等多种地址问题。

今天想记录的是使用 AddressSanitizer 检测内存泄漏的步骤,其实检测内存泄漏的功能目前已经被基本独立成了 LeakSanitizer,不过仍可以通过在 AddressSanitizer 工具中通过参数来开启和关闭使用。

检测步骤

其实使用 ASAN 检测内存泄漏还是比较简单的,g++4.8 以上的版本自带了 ASAN 工具,只要编译时指定好参数,编译完成后正常启动运行程序就可以了,只不过有些情况下只从检测报告中无法准确定位问题,需要借助一些工具进一步缩小检测范围。

泄漏发生在可执行程序本身

这种情况检测起来比较容易,编写如下测试代码:

//test.cpp

#include <iostream>

void func()
{
    int* p = new int(); // 内存泄漏的位置
    p = nullptr;
}

int main()
{
    func();
    std::cout << "test leak" << std::endl;
    return 0;
}

使用g++进行编译,编译时添加参数 -fsanitize=leak 就可以了,启动后可以清晰的展示出内存泄漏的位置 test.cpp:5,也就是 test.cpp 文件的第5行。

albert@home-pc:/mnt/d/data/cpp/testleak$ g++ test.cpp -g -o test --std=c++11 -fsanitize=leak
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test
test leak

=================================================================
==344==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7fc7d796d815 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xd815)
    #1 0x400967 in func() /mnt/d/data/cpp/testleak/test.cpp:5
    #2 0x400985 in main /mnt/d/data/cpp/testleak/test.cpp:11
    #3 0x7fc7d722083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: LeakSanitizer: 4 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$

这里有个小意外,将 int* p = new int(); 这句代码改成 int* p = new int[10]; 可以检测出内存泄漏如下:

albert@home-pc:/mnt/d/data/cpp/testleak$ g++ test.cpp -fsanitize=leak -g -o test --std=c++11
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test
test leak

=================================================================
==416==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 400 byte(s) in 1 object(s) allocated from:
    #0 0x7fdc0c16d975 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xd975)
    #1 0x400967 in func() /mnt/d/data/cpp/testleak/test.cpp:5
    #2 0x40097f in main /mnt/d/data/cpp/testleak/test.cpp:11
    #3 0x7fdc0ba2083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: LeakSanitizer: 400 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$

但是将 int* p = new int(); 这句代码改成 int* p = new int[1024]; 就无法检测是内存泄漏了,只能修改编译选项为 -fsanitize=address 才能检测出泄漏,目前还不知道真正的原因是什么。

albert@home-pc:/mnt/d/data/cpp/testleak$ g++ test.cpp -fsanitize=address -g -o test --std=c++11
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test
test leak

=================================================================
==432==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4096 byte(s) in 1 object(s) allocated from:
    #0 0x7f1d42b296b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
    #1 0x400b27 in func() /mnt/d/data/cpp/testleak/test.cpp:5
    #2 0x400b3f in main /mnt/d/data/cpp/testleak/test.cpp:11
    #3 0x7f1d4235083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: 4096 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$

泄漏发生在编译所需动态库中

如果内存泄漏发生在编译时使用的动态库中,那么这和上一种情况基本一致,可以直接编译后运行就能发现,测试代码如下

// myadd.h

int add(int a, int b);
// myadd.cpp

#include "myadd.h"

int add(int a, int b)
{
    int* p = new int(); // 内存泄漏的位置
    return a + b;
}
// test.cpp

#include "myadd.h"
#include <iostream>

int main()
{
    std::cout << "519 + 1 = " << add(519, 1) << std::endl;
    return 0;
}

添加编译选项 -fsanitize=leak 编译后运行,也可以直接显示出内存泄漏的位置,内存泄漏在 libmyadd.so 动态库中的 add 函数中。

albert@home-pc:/mnt/d/data/cpp/testleak$ g++ -shared -fPIC -o libmyadd.so myadd.cpp
albert@home-pc:/mnt/d/data/cpp/testleak$ g++ test3.cpp -L. -lmyadd -o test -Wl,-rpath=. -fsanitize=leak
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test
519 + 1 = 520

=================================================================
==493==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7ff1aff6d815 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xd815)
    #1 0x7ff1afd506b7 in add(int, int) (libmyadd.so+0x6b7)
    #2 0x4009cd in main (/mnt/d/data/cpp/testleak/test+0x4009cd)
    #3 0x7ff1af61083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: LeakSanitizer: 4 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$

泄漏发生在自定义加载的动态库中

这种情况要想精确定位问题就麻烦一些了,下面是用来测试的代码

// myadd.h

extern "C" int add(int a, int b);
// myadd.cpp

#include "myadd.h"

extern "C" int add(int a, int b)
{
    int* p = new int(); // 内存泄漏的位置
    return a + b;
}
// test.cpp

#include "myadd.h"
#include <dlfcn.h>
#include <iostream>

typedef int (*FUNC)(int a,int b);

int main() {
    void* handle = dlopen("./libmyadd.so", RTLD_LAZY);
    FUNC myadd = (FUNC)dlsym(handle,"add");

    int nVal = 0;
    std::cin >> nVal;
    std::cout << "519 + 1 = " << myadd(519, 1) << ", input:" << nVal << std::endl;

    dlclose(handle);
    return 0;
}

添加编译选项 -fsanitize=leak 编译后运行,输入数字618,程序运行结束,显示内存泄漏出现在 0x7fc88f0f06b7 (<unknown module>)

albert@home-pc:/mnt/d/data/cpp/testleak$ g++ -shared -fPIC -o libmyadd.so myadd.cpp -g
albert@home-pc:/mnt/d/data/cpp/testleak$ g++ test.cpp -ldl -o test -Wl,-rpath=. -g -fsanitize=leak
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test
618
519 + 1 = 520, input:618

=================================================================
==817==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7fc89076d815 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xd815)
    #1 0x7fc88f0f06b7  (<unknown module>)
    #2 0x400bc2 in main (/mnt/d/data/cpp/testleak/test+0x400bc2)
    #3 0x7fc88fe1083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: LeakSanitizer: 4 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$

unknown module

当使用 dlopen 的方式加载的动态库时,产生的内存泄漏常显示为 (<unknown module>),那是因为内存检测工具在程序退出时分析泄漏情况,而这时自定义加载的动态库往往已经手动调用 dlclose 关闭了,这时就会显示成 0x7fc88f0f06b7 (<unknown module>) 的显示。

maps

针对于出现 (<unknown module>) 的这种情况,可以通过查询 /proc/pid/maps 来辅助查询,maps 文件显示进程映射后的内存区域和访问权限,是程序正在运行时的信息,数据格式如下:

7f8c7adb6000-7f8c7adba000 rw-p 00000000 00:00 0
7f8c7adc0000-7f8c7af32000 r-xp 00000000 00:00 189413             /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f8c7af32000-7f8c7af3f000 ---p 00172000 00:00 189413             /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f8c7af3f000-7f8c7b132000 ---p 0017f000 00:00 189413             /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f8c7b132000-7f8c7b13c000 r--p 00172000 00:00 189413             /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f8c7b13c000-7f8c7b13e000 rw-p 0017c000 00:00 189413             /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f8c7b13e000-7f8c7b142000 rw-p 00000000 00:00 0
7f8c7b150000-7f8c7b153000 r-xp 00000000 00:00 243909             /lib/x86_64-linux-gnu/libdl-2.23.so
7f8c7b153000-7f8c7b154000 ---p 00003000 00:00 243909             /lib/x86_64-linux-gnu/libdl-2.23.so
7f8c7b154000-7f8c7b352000 ---p 00004000 00:00 243909             /lib/x86_64-linux-gnu/libdl-2.23.so
7f8c7b352000-7f8c7b353000 r--p 00002000 00:00 243909             /lib/x86_64-linux-gnu/libdl-2.23.so
7f8c7b353000-7f8c7b354000 rw-p 00003000 00:00 243909             /lib/x86_64-linux-gnu/libdl-2.23.so
7f8c7b360000-7f8c7b39f000 r-xp 00000000 00:00 247365             /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0
7f8c7b39f000-7f8c7b3a2000 ---p 0003f000 00:00 247365             /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0
7f8c7b3a2000-7f8c7b59e000 ---p 00042000 00:00 247365             /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0
7f8c7b59e000-7f8c7b5a0000 r--p 0003e000 00:00 247365             /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0
7f8c7b5a0000-7f8c7b5a1000 rw-p 00040000 00:00 247365             /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0
7f8c7b5a1000-7f8c7c1f4000 rw-p 00000000 00:00 0
7f8c7c200000-7f8c7c225000 r-xp 00000000 00:00 243945             /lib/x86_64-linux-gnu/ld-2.23.so
7f8c7c225000-7f8c7c226000 r-xp 00025000 00:00 243945             /lib/x86_64-linux-gnu/ld-2.23.so
  • 第一列:7f8c7b360000-7f8c7b39f000,表示本段内存映射的虚拟地址空间范围。
  • 第二列:r-xp,表示此段虚拟地址空间的属性。r表示可读,w表示可写,x表示可执行,ps共用一个字段,互斥关系,p表示私有段,s表示共享段,-表示没有权限。
  • 第三列:00000000,表示映射偏移。对有名映射,表示此段虚拟内存起始地址在文件中以页为单位的偏移。对匿名映射,它等于0或者vm_start/PAGE_SIZE。
  • 第四列:00:00,表示映射文件所属设备号。对有名映射来说,是映射的文件所在设备的设备号,对匿名映射来说,因为没有文件在磁盘上,所以没有设备号,始终为00:00。
  • 第五列:247365,表示映射文件所属节点号。对有名映射来说,是映射的文件的节点号。对匿名映射来说,因为没有文件在磁盘上,所以没有节点号,始终为0。
    第六列:/usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0,表示映射文件名或堆、栈。对匿名映射来说,是此段虚拟内存在进程中的角色。[stack]表示在进程中作为栈使用,[heap]表示堆。对有名来说,是映射的文件名。其余情况则无显示。

7f8c7b360000-7f8c7b39f000 r-xp 00000000 00:00 247365 /usr/lib/x86_64-linux-gnu/liblsan.so.0.0.0

这一行就展示了 liblsan.so 这个动态库映射的内存中位置和权限情况,liblsan.so 也就是 ASAN 工具用来检测内存泄漏的工具所依赖的动态库。

具体操作

  1. 启动一个终端,然后运行 test 程序,因为程序中要求从控制台读取一个变量,所以运行后程序会一直停留在控制台等待输入
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test

  1. 重新打开一个终端,查询 test 程序的进程id,然后拷贝对应的 maps 文件
albert@home-pc:/mnt/d/data/cpp/testleak$ ps -ef | grep test
albert     986   889  0 21:42 pts/0    00:00:00 ./test
albert     988   953  0 21:42 pts/1    00:00:00 grep --color=auto test
albert@home-pc:/mnt/d/data/cpp/testleak$ cp /proc/986/maps testmaps
  1. 在第一个终端中输入数字,程序运行结束,显示出内存泄漏信息
albert@home-pc:/mnt/d/data/cpp/testleak$ ./test

# 以下为新的信息,输入了515

515
519 + 1 = 520, input:515

=================================================================
==986==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7f8c7b36d815 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xd815)
    #1 0x7f8c79cf06b7  (<unknown module>)
    #2 0x400bc2 in main (/mnt/d/data/cpp/testleak/test+0x400bc2)
    #3 0x7f8c7aa1083f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: LeakSanitizer: 4 byte(s) leaked in 1 allocation(s).
albert@home-pc:/mnt/d/data/cpp/testleak$
  1. 从检测报告中看到 0x7f8c79cf06b7 (<unknown module>),在备份的 testmaps 文件中查找范围,发现处于下面一段之中
640000000000-640000003000 rw-p 00000000 00:00 0
7f8c79cf0000-7f8c79cf1000 r-xp 00000000 00:00 282                /mnt/d/data/cpp/testleak/libmyadd.so
7f8c79cf1000-7f8c79cf2000 ---p 00001000 00:00 282                /mnt/d/data/cpp/testleak/libmyadd.so
7f8c79cf2000-7f8c79ef0000 ---p 00002000 00:00 282                /mnt/d/data/cpp/testleak/libmyadd.so
7f8c79ef0000-7f8c79ef1000 r--p 00000000 00:00 282                /mnt/d/data/cpp/testleak/libmyadd.so
7f8c79ef1000-7f8c79ef2000 rw-p 00001000 00:00 282                /mnt/d/data/cpp/testleak/libmyadd.so
7f8c79f00000-7f8c7a000000 rw-p 00000000 00:00 0
  1. 至此发现问题出现在 libmyadd.so 这个动态库中,再用 0x7f8c79cf06b7 减去动态链接库基地址 7f8c79cf0000,得到偏移量为 0x6b7,此时使用 addr2line 工具进行转化。
albert@home-pc:/mnt/d/data/cpp/testleak$ addr2line  -C -f -e /mnt/d/data/cpp/testleak/libmyadd.so 0x6b7
add
/mnt/d/data/cpp/testleak/myadd.cpp:4
  1. 至此就找到了内存泄漏的确切位置,在/mnt/d/data/cpp/testleak/myadd.cpp文件第4行的 add 函数之中。

总结

  • 在 C++11 之后尽可能使用智能指针来管理在堆上申请的内存,shared_ptrweak_ptrunique_ptr 能帮我们减少许多麻烦
  • 想要检测程序内存用用问题, AddressSanitizer 是一个不错的选择,其中有关内存泄漏的检测已经被整合到 LeakSanitizer 工具中
  • 当程序中的内存泄漏发生在 dlopen 加载的动态库中时,常常出现 (<unknown module>) 的情况,这时需要借助 proc/pid/maps 文件和 addr2line 工具来完成精确定位。

==>> 反爬链接,请勿点击,原地爆炸,概不负责!<<==

祝融落地。一百年了,还没有什么事情是做不到的,我们需要的是时间,我等着看你们在真正的力量面前瑟瑟发抖~

相关文章:

  • C++对我来说简直就是星辰大海,为了避免翻船,我选择从小河沟出发
  • cpplint中filter参数的每个可选项的含义
  • 手把手搭建一个redis集群
  • 换个角度来看看C++中的左值、右值、左值引用、右值引用
  • C/C++中的数据类型转换()/static_cast/dynamic_cast/const_cast/reinterpret_cast
  • C++11中std::move和std::forward到底干了啥
  • 使用box2dweb做一个下落的小球,宝宝玩的不亦乐乎
  • C++中使用std::sort自定义排序规则时要注意的崩溃问题
  • 从一个小题中的应用来体会下std::tie的便利之处
  • Floyd-Warshall——仅用4行代码就能解决多源最短路径问题的算法
  • Dijkstra——通过不断松弛来解决单源最短路径问题的算法
  • C++11中的std::atomic保证的原子性是什么
  • .bat批处理(十):从路径字符串中截取盘符、文件名、后缀名等信息
  • linux环境下从路径字符串中截取目录和文件名信息
  • MD5是用来加密的吗?BCrypt又是什么呢
  • CentOS从零开始部署Nodejs项目
  • docker python 配置
  • Golang-长连接-状态推送
  • Netty 4.1 源代码学习:线程模型
  • OSS Web直传 (文件图片)
  • PHP面试之三:MySQL数据库
  • Promise初体验
  • spring boot下thymeleaf全局静态变量配置
  • SQLServer之索引简介
  • swift基础之_对象 实例方法 对象方法。
  • Theano - 导数
  • TiDB 源码阅读系列文章(十)Chunk 和执行框架简介
  • 从零开始的webpack生活-0x009:FilesLoader装载文件
  • 聚簇索引和非聚簇索引
  • 聊聊spring cloud的LoadBalancerAutoConfiguration
  • 如何将自己的网站分享到QQ空间,微信,微博等等
  • 如何解决微信端直接跳WAP端
  • ​ 无限可能性的探索:Amazon Lightsail轻量应用服务器引领数字化时代创新发展
  • #ifdef 的技巧用法
  • #NOIP 2014# day.1 T3 飞扬的小鸟 bird
  • $GOPATH/go.mod exists but should not goland
  • $L^p$ 调和函数恒为零
  • (1)bark-ml
  • (2)(2.10) LTM telemetry
  • (2022 CVPR) Unbiased Teacher v2
  • (4.10~4.16)
  • (html5)在移动端input输入搜索项后 输入法下面为什么不想百度那样出现前往? 而我的出现的是换行...
  • (MATLAB)第五章-矩阵运算
  • (Redis使用系列) Springboot 使用redis实现接口Api限流 十
  • (二十五)admin-boot项目之集成消息队列Rabbitmq
  • (附源码)spring boot校园拼车微信小程序 毕业设计 091617
  • (十七)devops持续集成开发——使用jenkins流水线pipeline方式发布一个微服务项目
  • (转)德国人的记事本
  • ***通过什么方式***网吧
  • .NET 中使用 TaskCompletionSource 作为线程同步互斥或异步操作的事件
  • .NetCore实践篇:分布式监控Zipkin持久化之殇
  • .NET委托:一个关于C#的睡前故事
  • .NET值类型变量“活”在哪?
  • @AliasFor注解
  • [ vulhub漏洞复现篇 ] GhostScript 沙箱绕过(任意命令执行)漏洞CVE-2019-6116