使用valgrind来检查内存泄漏

之前写代码，有少量的内存泄露，平时没发现，长时间运行才发现问题。为以后更方便的检测内存泄漏问题，于是学习使用了valgrind来对内存泄漏进行检测。valgrind不止可以检测内存泄露，但目前只使用这一功能。

1.安装

去以下链接下载安装文件下载链接

下载完成后解压，终端进入解压后的文件夹，依次输入

./configure
make
make install

如遇提示权限不够，make前加sudo

如果想验证是否安装完成，在终端输入

valgrind --version

，若安装成功，会输出相应版本，如图

2.检测内存泄漏

终端进入可执行文件所在的文件夹，输入

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --undef-value-errors=no --log-file=log ./可执行文件名

即可在终端所在文件夹下生成log文件，如图



在log文件最后会有个summary，其中对内存泄露进行了分类，总共有五类：

(1) “definitely lost” 意味着你的程序一定存在内存泄露；

(2)”indirectly lost”意味着你的程序一定存在内存泄露，并且泄露情况和指针结构相关

(3) “possibly lost” 意味着你的程序一定存在内存泄露，除非你是故意进行着不符合常规的操作，例如将指针指向某个已分配内存块的中间位置。

(4) “still reachable” 意味着你的程序可能是没问题的，但确实没有释放掉一些本可以释放的内存。这种情况是很常见的，并且通常基于合理的理由。

(5)”suppressed” 意味着有些泄露信息被压制了。在默认的 suppression 文件中可以看到一些 suppression 相关设置。

其中，如果二叉树的根节点被判定为”definitely lost”，则其所有子节点将被判定为”indirectly lost”，而如果你正确修复了类型为 “definitely lost” 的根节点泄露，那么类型为 “indirectly lost” 的子节点泄露也会随着消失。

对于如上图所示的情况，posslbly lost其实并没有造成内存上的影响，如果想要过滤掉该类报告信息，可以加入

--show-possibly-lost=no

，而对于”still reachable” ，同样可以通过

--show-reachable=yes

来控制是否输出相应的信息。

如果某些需要的库没有找到，用指令

export LD_LIBRARY_PATH=/usr/local/mysql/lib:$LD_LIBRARY_PATH

进行添加

3.查看发生泄露的具体位置

在log中由summary往上翻即可看到对应的错误，错误是不断细化的，比如



这样的是一个错误，先告诉你出现了多少的内存泄露，然后从最里层不断往外部函数显示：先说是calloc造成的错误，然后不断往外部函数显示。可以从下往上进行查看，比如先说main()函数发生了泄露，往上看到是main()中的init()函数，再往上init()中的init_detectionmodel，如此不断细定位泄露位置。