内存问题检查利器——Purify

https://ibm-rational-purify-for-windows.updatestar.com/edit

我们都知道软件的测试（在以产品为主的软件公司中叫做QA—Quality Assessment）占了整个软件工程的30% -50%，但有这么一种说法，即使是最优秀测试专家设计出来的测试案例，也无法彻底地检测到内存上的问题。  

使用C/C++开发的团队一定有被其内存问题折磨过的经历，内存问题一直是C/C++开发人员的心头之痛。特别当程序越来越多时，类的继承和关联越来越多时，内存问题也就越来越多，很多时候，开发人员在不经意的时候就带入了内存问题。这是C/C++世界中很难避免的东西，哪怕是有10年以上开发经验的老手，也难以避免或是杜绝内存问题。

而且，内存的问题是让人很难察觉的，特别是对于内存问题排名第一的Memory Leak来说，在几万行代码中出现Memory Leak的机率几乎是100%，而且要靠一般的手段是很难检测出这种程序错误的。它并不像“野指针”或是“数组越界”那么容易暴露出来（这些会让程序异常退出，而Memory Leak则不会）。当你发现你的服务器端的程序，每隔一个月（或是更长的时间）就把服务器上的内存全部耗尽时，让服务器有规律地每过几个月就当机一次，那么你的程序可能是中了Memory Leak了，同时，你会发现在数十万行代码中寻找这种Memory Leak无异于大海捞针。

于是，正如《黑客帝国II》中描述的那样，当你的程序越来越大，越来越复杂的时候，你会发现程序就越来越不受你的控制，有一些让你内存出现问题乃至让你应用程序崩溃的变量，他们生存在系统的边缘，你怎么找也找不到，这种情况下，除了用程序测试程序，别无其它的方法。对于C/C++内存问题中的Memory Leak这种顶级杀手，那怕最牛的程序员再加上最牛的系统架构师也很难把其找出来，对此，我们只有依靠程序，用程序去寻找这种系统的BUG。这么让我们事半功倍。

在我们寻求解决内存问题的同时，让我们所感到幸运的时，目前，已经有许多小的软件可供我们选择，如MallocDebug，Valgrind，Kcachegrind，dmalloc，NuMega，BoundsCheck，ParaSoft ，Insure++等等，在这里，我想向大家介绍的是Rational 公司（呵呵，应该是IBM了）的 Purify，这是我觉得最专业，也是最强大的内存检测工具。

Purify 所支持的操作系统有Windows 2000/XP Professional/NT、Sun Solaris、HP-UX、SGI-IRIX。我不知道其支不支持Linux，但在其网站上，我并没有看到这样的信息，但又听别人说他支持，所以在这里我不敢断言它不支持，想想要做UNIX下的软件能有不支持Linux的吗？可能很少吧。

下面，是我所使用的Purify的版本和运行Purify的操作系统：

> purify -version

Version 2003.06.00 Solaris 2

> uname -a

SunOS hostname 5.8 Generic_108528-11 sun4u sparc SUNW,Ultra-60

我会基于这个版本向你介绍Purify的强大功能。

二、           Purify简介

在C/C++的软件开发中，没有任何一种工具可以让你的应用程序避免引入内存问题，但是我们可以使用诸如Purify这样的工具对已经做好了的程序进行内存问题的检查。Purify的强大之处是可以找到应用程序中全面的内存问题，并可以和GDB/DBX等调试器以配合使用，让你对你的内存错误一目了然。

Purify是一个Run-Time的工具，也就是说只有在程序运行过程中，根据程序的运行情况来查看在某种运行条件下程序是否有内存上的问题，它可以在一个非常复杂的程序中查找内存错误，包括那种多进程或多线程的程序，它也可以进行测试。

Purify对程序中的每一个内存操作都进行检测，并对精确报告内存出现错误的变量和语句，以提供出现错误原因的分析。Purify主要检测的是下面这些内存错误：

l         数组内存是否越界读/写。

l         是否使用了未初始化的内存。

l         是否对已释放的内存进行读/写。

l         是否对空指针进行读/写。

l         内存漏洞。

在软件工程中，以我的经验而言，最好是在编码阶段时就使用Purify检测内存存问题，一直到交给测试人员测试。请相信我，在一个大型的C/C++软件产品中，即使检测出了内存问题，离真正地解决它还有一定的距离，所以为了让这个“距离”不算太远，最好还是在功能模块完成时就进行Purify的内存检测。

一般而言，在软件测试中，首要的是软件的功能测试，然后是反面案例测试，再而是压力测试。就我个人经验而言，使用内存检测工具的阶段应该是编码阶段、模块合并后、以及程序逻辑测试完成以后，直到产品发布前，也要做一个内存测试。

要使用Purify这个工具很简单，首先在你安装好了的Purify的目录上你会看到两个Shell脚本：purifyplus_setup.csh（对应于C-Shell）purifyplus_setup.sh（对应于标准Shell）。你先执行一下这两个脚本，以便让Purify设置好一些环境参数，如：

> source purifyplus_setup.csh

而对于你的程序而言，你需要这样使用：

   　> purify cc –g –o myProgram myProgram.c

     > purify cc –g –c –o myLib.o myLib.c

就这么简单，然后你只要运行你的程序就行了，Purify会向你提交一份内存问题的报告清单，以供你分析。Purify使用的是OCI（Object Code Insertion）技术，它会在你的目标程序中插入一些它自己的函数，这些函数主要都是内存检测的语句，这些语句将会放置在程序中所有，内存操作之前，一旦在程序运行时发现内存问题，Purify所插入的这些语句就会向你报告。一般来说，所有的内存检测工具都是这样工作的。

当被Purify编译过的程序运行时，Purify会弹出一个图形界面的窗口，来向你报告内存问题。如下所示：

点击三角符号后将出现更为详细的信息：

Purify在报告内存问题的时候，可以指出源程序中哪个地方出现内存问题，但对于内存泄漏而言，它只能指出出现问题的内存是哪一块，也就是指出内存是在哪里被分配的，而不是指出内存泄露是如何发生的。这是比较合乎情理的，所以，即使你知道那块内存发生了泄漏，你也不一定能找到究竟在什么时候发生的。当然，如果你让Purify配合GDB一起使用，那么要找到这种问题的根本原因，也不是什么困难的事情。

valgrind 工具介绍和简单的使用

最近老是遇上各种奇奇怪怪的core dump，不太会分析的情况下看到了这款工具。在这记录分享下。

Valgrind 是个开源的工具，功能很多。例如检查内存泄漏工具—memcheck。

Valgrind 安装：

去官网下载： http://valgrind.org/downloads/current.html#current

安装过程：（可以直接查看README文档来确认安装过程）

    tools/valgrind-3.12.0> pwd
    /proj/MPS_DEV_REPO/xchonxu/tools
    > tar -jxf valgrind-3.12.0.tar.bz2
    > cd /proj/MPS_DEV_REPO/xchonxu/tools/valgrind-3.12.0
    > vim README
    > ls
    > ./autogen.sh
    > ./configure –prefix=/home/xchonxu/bin
    > make
    > make install

    验证是否成功：
    > cd ~
    > ls
    > cd bin/
    > ls
    > cd bin/
    > ls
    > ./valgrind ls -l
    > ./valgrind –leak-check=full ls -l

Valgrind 命令介绍：

用法: valgrind [options] prog-and-args 
[options]: 常用选项，适用于所有Valgrind工具

    -tool=<name> 最常用的选项。运行 valgrind中名为toolname的工具。默认memcheck。

        memcheck ——> 这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。

        callgrind ——> 它主要用来检查程序中函数调用过程中出现的问题。

        cachegrind ——> 它主要用来检查程序中缓存使用出现的问题。

        helgrind ——> 它主要用来检查多线程程序中出现的竞争问题。

        massif ——> 它主要用来检查程序中堆栈使用中出现的问题。

        extension ——> 可以利用core提供的功能，自己编写特定的内存调试工具

    -h –help 显示帮助信息。
    -version 显示valgrind内核的版本，每个工具都有各自的版本。
    -q –quiet 安静地运行，只打印错误信息。
    -v –verbose 更详细的信息, 增加错误数统计。
    -trace-children=no|yes 跟踪子线程? [no]
    -track-fds=no|yes 跟踪打开的文件描述？[no]
    -time-stamp=no|yes 增加时间戳到LOG信息? [no]
    -log-fd=<number> 输出LOG到描述符文件 [2=stderr]
    -log-file=<file> 将输出的信息写入到filename.PID的文件里，PID是运行程序的进行ID
    -log-file-exactly=<file> 输出LOG信息到 file
    -log-file-qualifier=<VAR> 取得环境变量的值来做为输出信息的文件名。 [none]
    -log-socket=ipaddr:port 输出LOG到socket ，ipaddr:port

LOG信息输出

    -xml=yes 将信息以xml格式输出，只有memcheck可用
    -num-callers=<number> show <number> callers in stack traces [12]
    -error-limit=no|yes 如果太多错误，则停止显示新错误? [yes]
    -error-exitcode=<number> 如果发现错误则返回错误代码 [0=disable]
    -db-attach=no|yes 当出现错误，valgrind会自动启动调试器gdb。[no]
    -db-command=<command> 启动调试器的命令行选项[gdb -nw %f %p]

适用于Memcheck工具的相关选项：

    -leak-check=no|summary|full 要求对leak给出详细信息? [summary]
    -leak-resolution=low|med|high how much bt merging in leak check [low]
    -show-reachable=no|yes show reachable blocks in leak check? [no]

最常用的命令格式：

valgrind –tool=memcheck –leak-check=full ./test

案例介绍：

申请内存未释放：

xchonxu/testCode> cat testValgrind.cc 
#include <iostream>

using namespace std;

int main()
{
    int *a = new int(2);

    //delete a;

    return 0;
}

xchonxu/testCode> g++ -g -o testValgrind testValgrind.cc
xchonxu/testCode> ~/bin/bin/valgrind –tool=memcheck –leak-check=full ./testValgrind
==3598== Memcheck, a memory error detector
==3598== Copyright (C) 2002-2015, and GNU GPL’d, by Julian Seward et al.
==3598== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==3598== Command: ./testValgrind
==3598== 
==3598== 
==3598== HEAP SUMMARY:
==3598==     in use at exit: 4 bytes in 1 blocks
==3598==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==3598== 
==3598== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3598==    at 0x4C292DF: operator new(unsigned long) (vg_replace_malloc.c:332)
==3598==    by 0x4007AF: main (testValgrind.cc:7)
==3598== 
==3598== LEAK SUMMARY:
==3598==    definitely lost: 4 bytes in 1 blocks
==3598==    indirectly lost: 0 bytes in 0 blocks
==3598==      possibly lost: 0 bytes in 0 blocks
==3598==    still reachable: 0 bytes in 0 blocks
==3598==         suppressed: 0 bytes in 0 blocks
==3598== 
==3598== For counts of detected and suppressed errors, rerun with: -v
==3598== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

    Memcheck将内存泄露分为两种，一种是可能的内存泄露（Possibly lost），另外一种是确定的内存泄露（Definitely lost）。Possibly lost 是指仍然存在某个指针能够访问某块内存，但该指针指向的已经不是该内存首地址。Definitely lost 是指已经不能够访问这块内存。而Definitely lost又分为两种：直接的（direct）和间接的（indirect）。直接和间接的区别就是，直接是没有任何指针指向该内存，间接是指指向该内存的指针都位于内存泄露处。在上述的例子中，根节点是directly lost，而其他节点是indirectly lost

原理：