之前写代码，有少量的内存泄露，平时没发现，长时间运行才发现问题。为以后更方便的检测内存泄漏问题，于是学习使用了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，如此不断细定位泄露位置。