故障定位手段

1 内存泄露

1.1 原因

1、malloc/new 申请的内存没有主动释放
2、new 与 free 混用，malloc 与 delete 混用
3、使用 new 开辟数组时，delete 忘记加 []
4、类的析构函数没有定义为虚函数## 1.2 排查

1.2.1 查内存占用情况

free```free### 1.2.2 valgrind 工具```cpp yuminstallvalgrind

• 应用环境：Linux
• 编程语言：C/C++
• 编译时： 编译时加上-g选项，如 gcc -g filename.c -o myapp.exe
• 定位输出：valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./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)
  重复free

1.2.3 Tcmalloc

Tcmalloc 为 Google 编写的开源内存组件，此组件有 2 个功效：

• 使用自己的内存管理，可以替换 ulibc 或者 glibc 的内存
• 可以探测 HEAP 内存泄漏，当然还有其他很强大的功能，本文只讲述内存泄漏的排查。1. 设置环境变量：
  export LD_PRELOAD=/home/dofs_core/server/lib/libtcmalloc.so

2. 运行程序：

HEAPPROFILE=/model/tcmalloc/hicore HEAP_PROFILE_ALLOCATION_INTERVAL=1073741824./hicore&

第一个参数是生成的heap的文件名以hicore开头命名、每隔1G写一次dump一次写heap文件

3. 用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

1. 查看当前系统是否已开启core文件记录
   ulimit -c如果结果是0说明尚未开启，需要进行设置
   

2. 开启core文件记录

ulimit-c100单位是blockulimit-cunlimited 表示没有限制core文件大小

3. 设置生成的core文件路径， 以及core文件命名格式

查看当前core文件存放路径及格式：cat /proc/sys/kernel/core_pattern

4. 设置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的命令名(可执行文件名)注：以上设置可以放在启动配置中。

gdb+coredump

5. 代码测试生成coredump文件

intmain(intargc,char*argv[]){int*p=0;*p=100;return0;}

编译时需要添加上-g参数：gcc main.c -o main -g

6. 使用gdb查看core文件

gdb./main core_main.30884.1646125360——gdb 对应的可执行文件对应的coredump文件

从信息中可直接看出是源码main.c第4行，*p = 100;直接导致core文件。

pstack+coredump

current_pid=$!#获取当前线程ID pstack pid #当前线程ID

4 死锁

4.1 使用调试工具：可以使用GDB、Valgrind

4.2 pstack

通过pstack，打印堆栈信息，通过多次pstack堆栈信息，发现某些线程阻塞到同一函数，即大概率为死锁现象。

#include<mutex>#include<memory>classMUTEXTEST{public:voidmutexCall(){std::lock_guard<std::mutex>lock(_mutex);mutexFun2();}voidmutexFun2(){std::lock_guard<std::mutex>lock(_mutex);_value++;}private:int_value=0;std::mutex _mutex;};intmain(intargc,char*argv[]){std::cout<<"will go to mutex begin"<<std::endl;MUTEXTEST mutex_instance;mutex_instance.mutexCall();std::cout<<"will go to mutex finished"<<std::endl;return0;}

获取进行pid

ps-elf|grep vtest

打印堆栈信息

pstack14270

通过多次堆栈打印，发现线程阻塞到了mutexFun2的调用上，重点分析mutexCall->mutexFun2的调用逻辑。