C/C++ 内存泄漏检查工具 valgrind

C/C++ 内存泄漏检查工具 valgrind

前言

因为项目问题，需要使用 HDR 暗光增强。

于是用了已有的 HDR 暗光增强功能，但是在 Android 环境下测试时，发现会遇到以下错误。

由于不是必现，且没有明显的规律，没有有用的信息。

查阅资料说可能是由于 JNI 层的一些非法地址操作，踩坏了 Android 的堆栈内存，导致线程崩溃。

由于前一版程序经过 20 小时的压力测试，所以矛头指向新加入的 HDR 暗光增强功能。

但是因为没有申请到 HDR 暗光增强源代码的权限，只能把问题反馈给相关人员。

相关人员查了很久，只查到了一处内存泄漏。

修改完后测试，长时间运行正常，以为好了。。。结果吃个饭回来，还是出事了。

好吧，不得已申请到源代码权限，打算自己干。

但是这个功能的确比较复杂，估计老方法一行行分析耗时严重。

最后决定使用内存泄漏检测工具进行查找。

valgrind 简介

前面废话太多，上正题！

Valgrind 是用于构建动态分析工具的探测框架。它包括一个工具集，每个工具执行某种类型的调试、分析或类似的任务，以帮助完善你的程序。Valgrind 的架构是模块化的，所以可以容易地创建新的工具而又不会扰乱现有的结构。

针对不同的情况，提供多种功能的工具：

工具	说明	功能
Memcheck	内存错误检测器	能够发现开发中绝大多数内存错误使用情况
Callgrind	调用图缓存生成分析器	检查程序中函数调用过程中出现的问题
Cachegrind	缓存和分支预测分析器	检查程序中缓存使用出现的问题
Helgrind	线程错误检测	检查多线程程序中出现的竞争问题
Massif	堆分析器	检查程序中堆栈使用中出现的问题
Extension	DHAT、BBV、SGCheck、	可以利用 core 提供的功能，自己编写特定的内存调试工具

Memcheck 是 valgrind 应用最广泛的工具。它是一个重量级的内存检查器，能够发现 C 或者 C++ 在开发过程中绝大多数导致程序崩溃或者不可预知的行为的内存相关的错误，比如：使用未初始化的内存、使用已释放内存、内存访问越界等。

这次我们主要介绍 Memcheck 工具

使用 valgrind

下载：valgrind Current Releases

# 解压
bzip2 -d valgrind-3.14.0.tar.bz2

tar -xvf valgrind-3.14.0.tar

# 进入目录
cd valgrind-3.14.0/

# 生成 Makefile 文件
./configure

# 编译
make

# 安装
# sudo make install
make install

测试 valgrind 是否有效

测试命令：valgrind ls -l （测试 ls -l 命令是否内存情况）

可以看到有类型以下的运行结果：

==17057== Memcheck, a memory error detector
==17057== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17057== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==17057== Command: ls -l
==17057==
total 372
-rw-r--r-- 1 root root  11699 Feb 27 07:46 CMakeCache.txt
drwxr-xr-x 5 root root   4096 Feb 27 07:30 CMakeFiles
-rw-r--r-- 1 root root   6344 Feb 27 07:46 Makefile
-rw-r--r-- 1 root root   1384 Feb 27 07:46 cmake_install.cmake
-rw-r--r-- 1 root root 351584 Feb 27 07:46 judgeHdr
==17057==
==17057== HEAP SUMMARY:
==17057==     in use at exit: 19,666 bytes in 12 blocks
==17057==   total heap usage: 122 allocs, 110 frees, 75,309 bytes allocated
==17057==
==17057== LEAK SUMMARY:
==17057==    definitely lost: 0 bytes in 0 blocks
==17057==    indirectly lost: 0 bytes in 0 blocks
==17057==      possibly lost: 0 bytes in 0 blocks
==17057==    still reachable: 19,666 bytes in 12 blocks
==17057=&#