文章目录1 内存泄露1.1 原因1.2.1 查内存占用情况1.2.3 Tcmalloc2 内存越界gdb调试vargrind重写函数3 core dumpgdbcoredumppstackcoredump4 死锁4.1 使用调试工具可以使用GDB、Valgrind4.2 pstack1 内存泄露1.1 原因1、malloc/new 申请的内存没有主动释放2、new 与 free 混用malloc 与 delete 混用3、使用 new 开辟数组时delete 忘记加 []4、类的析构函数没有定义为虚函数## 1.2 排查1.2.1 查内存占用情况freefree### 1.2.2 valgrind 工具cpp yuminstallvalgrind应用环境Linux编程语言C/C编译时 编译时加上-g选项如 gcc -g filename.c -o myapp.exe定位输出valgrind --toolmemcheck --leak-checkyes --show-reachableyes ./filename就会看到内存使用报告设计思路根据软件的内存操作维护一个有效地址空间表和无效地址空间表进程的地址空间优缺点能够检测使用未初始化的内存 (Use of uninitialised memory)使用已经释放了的内存 (Reading/writing memory after it has been free’d)使用超过malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)重复free1.2.3 TcmallocTcmalloc 为 Google 编写的开源内存组件此组件有 2 个功效使用自己的内存管理可以替换 ulibc 或者 glibc 的内存可以探测 HEAP 内存泄漏当然还有其他很强大的功能本文只讲述内存泄漏的排查。1. 设置环境变量export LD_PRELOAD/home/dofs_core/server/lib/libtcmalloc.so运行程序HEAPPROFILE/model/tcmalloc/hicore HEAP_PROFILE_ALLOCATION_INTERVAL1073741824./hicore第一个参数是生成的heap的文件名以hicore开头命名、每隔1G写一次dump一次写heap文件用pprof分析heap文件1、/model/tcmalloc/目录中会生成很多heap文件然后用pprof将heap文件收获的堆栈信息输出到txt文档中进行查看./pprof --lib_prefix/opt/rockchip/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib64,/opt/rockchip/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/lib64,./lib --text --lines ./hicore ./hicore.0017.heap ./text_0017.txt命令样式./pprof --text ./进程名 heap文件名这个文件可能会生成很多 输出的txt文档名上图为pprof分析输出的文本图可通过对上图的内存申请大小进行分析排查可定位内存泄漏问题并能定位到源码中的位置。2 内存越界gdb调试vargrind能够检查出来内存越界和泄露重写函数3 core dump查看当前系统是否已开启core文件记录ulimit -c如果结果是0说明尚未开启需要进行设置开启core文件记录ulimit-c100单位是blockulimit-cunlimited 表示没有限制core文件大小设置生成的core文件路径 以及core文件命名格式查看当前core文件存放路径及格式cat /proc/sys/kernel/core_pattern设置core文件存访路径echo/home/liang/coredump_test/core_%e.%p.%t/proc/sys/kernel/core_pattern%p 进程id%u 用户id%g 用户组id%s 导致产生core的信号%t core文件生成时时间%h 主机名%e 导致产生core的命令名(可执行文件名)注以上设置可以放在启动配置中。gdbcoredump代码测试生成coredump文件intmain(intargc,char*argv[]){int*p0;*p100;return0;}编译时需要添加上-g参数gcc main.c -o main -g使用gdb查看core文件gdb./main core_main.30884.1646125360——gdb 对应的可执行文件对应的coredump文件从信息中可直接看出是源码main.c第4行*p 100;直接导致core文件。pstackcoredumpcurrent_pid$!#获取当前线程ID pstack pid #当前线程ID4 死锁4.1 使用调试工具可以使用GDB、Valgrind4.2 pstack通过pstack打印堆栈信息通过多次pstack堆栈信息发现某些线程阻塞到同一函数即大概率为死锁现象。#includemutex#includememoryclassMUTEXTEST{public:voidmutexCall(){std::lock_guardstd::mutexlock(_mutex);mutexFun2();}voidmutexFun2(){std::lock_guardstd::mutexlock(_mutex);_value;}private:int_value0;std::mutex _mutex;};intmain(intargc,char*argv[]){std::coutwill go to mutex beginstd::endl;MUTEXTEST mutex_instance;mutex_instance.mutexCall();std::coutwill go to mutex finishedstd::endl;return0;}获取进行pidps-elf|grep vtest打印堆栈信息pstack14270通过多次堆栈打印发现线程阻塞到了mutexFun2的调用上重点分析mutexCall-mutexFun2的调用逻辑。