Chinaunix首页 | 论坛 | 博客
  • 博客访问: 192470
  • 博文数量: 73
  • 博客积分: 5000
  • 博客等级: 大校
  • 技术积分: 1160
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-23 15:53
文章分类

全部博文(73)

文章存档

2011年(1)

2009年(72)

我的朋友

分类: LINUX

2009-04-23 17:11:19

CC++内存问题检查利器——Purify收藏

 

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

 

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

 

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

 

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

 

Purify 所支持的操作系统有Windows 2000/XP Professional/NTSun SolarisHP-UXSGI-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使用的是OCIObject Code Insertion)技术,它会在你的目标程序中插入一些它自己的函数,这些函数主要都是内存检测的语句,这些语句将会放置在程序中所有,内存操作之前,一旦在程序运行时发现内存问题,Purify所插入的这些语句就会向你报告。一般来说,所有的内存检测工具都是这样工作的。

 

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

 

 

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

 

 

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

三、           示例

假设我们现在有这样一段程序:hello.c


#include

#include

 

static char *helloWorld = "Hello, World";

 

main()

{

   char *mystr = malloc(strlen(helloWorld));

 

   strncpy(mystr, helloWorld, 12);

   printf("%s\n", mystr);

}

 

很明显,这段程序中有内存上的错误,假设我们疏忽了这些错误,当我们使用Purify进行测试时,我们会发现这段程序中的内存错误在Purify下很容易就被找出来了。首先,我们要做的是使用Purify编译这段程序:

 

> purify gcc -g -o hello hello.c

Purify 2003.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2002 Rational Software Corp.  All rights reserved. 

Instrumenting: cckc6pUD.o  Linking

 

记得加上“-g”的选项,不然,purify不能显示源程序。好了,现在在当前目录下产生了可执行文件——hello,在运行hello之前,我们还得注意,执行被Purify编译过的程序,有可能会出现X-Windows,所以请注意设置DISPLAY环境,如果你是在WindowsTelnet客户端下执行,那么你可以在Windows下装一个叫做Exceed的工具软件,它可以方便地把X-Window显示在你的Windows桌面上)

 

好了,我们现在执行hello程序,就可以看到下面的一个窗口:

 

 

我们可以看到Purify的报告中有两个内存错误,一个是ABRArray Bounds Read)——数组越界读,一个是12个字节的Memory Leaked,展开小三角符号,我们可以看到更为详细报告:

 

展开ABR错误后,我们可以看到,ABR错误的产生是由printf产生的,而产生错误的内存是mystr。通过观察,我们马上可以发现为会什么会出现ABR错误,原因是C/C++中的字符串都是以“\0”结尾的,而我们分配字符串时,应该要比实际长度多一,以存放结束符,而我们以后面调用的strncpy只拷贝了字符串的有效内容,并没有在字符串最后加上一个结束符。而系统调用printf输出字符串内容直至遇到结束符,所以当其访问到12个长度时,还没有发现结束,于是继续向下访问,于是就出现了ABR错误。

 

 

好了,让我们再来看看Memory Leaked的报告信息:

 

我们可以看到,Purify指出了那块内存出现了内存泄露,泄露了多少个字节。通过Purify的报告,再加上我们对C/C++基础的了解,我们立马知道mystr是在堆上分配的内存,所以必须要我们自己手动释放,查看程序,我们发现我们忘了free ( mystr )

 

好了,现在我们可以根据Purify报告修改我们的程序了:

 

#include

#include

 

static char *helloWorld = "Hello, World";

 

main()

{

       char *mystr = malloc(strlen(helloWorld)+1);

 

   strncpy(mystr, helloWorld, 12);

   mystr[12]=”\0”;

 

   printf("%s\n", mystr);

   free(mystr);

}

 

现在,我们再用Purify重新编译我们的程序,然后运行,我们可以看到Purify会报告没有任何的内存问题。其实,使用Purify很简单,在后面,我将对Purify的各种常用特性做比较全面的阐述。

 

四、           内存问题一览

下面是Purify所能检测到的内存信息表:

 

内存信息

描述

错误等级

ABR

Array Bounds Read 数组越界读

3

ABW

Array Bounds Write 数组越界写

2

BSR

Beyond Stack Read 越栈读

3

BSW

Beyond Stack Write 越栈写

3

COR

Core Dump Imminent 非法操作

1

FIU

File Descriptors In Use 文件描述符被使用

4

FMM

Freeing Mismatched Memory 释放错误内存

2

FMR

Free Memory Read 对已释放内存读

3

FMW

Free Memory Write 对已释放内存写

2

FNH

Freeing Non Heap Memory 释放非堆内存

2

FUM

Freeing Unallocated Memory 释放了没有分配的内存

2

IPR

Invalid Pointer Read 非法指针读

1

IPW

Invalid Pointer Write 非法指针写

1

MAF

Malloc Failure 分配内存失败

4

MIU

Memory In-Use 内存正在使用

4

MLK

Memory Leak 内存泄露

3

MRE

Malloc Reentrancy Error remalloc

2

MSE

Memory Segment Error 内存段错

3

NPR

Null Pointer Read 空指针读

1

NPW

Null Pointer Write 空指针写

1

PAR

Bad Parameter 错误的参数

3

PLK

Potential Leak 潜在的内存泄露

3

SBR

Stack Array Bounds Read 栈数组越界读

3

SBW

Stack Array Bounds Write 栈数级越界写

2

SIG

Signal 信号

4

SOF

Stack Overflow 栈溢出

3

UMC

Uninitialized Memory Copy 对未初始化的内存进行拷贝

3

UMR

Uninitialized Memory Read 对未初始化的内存读

3

WPF

Watchpoint Free 释放被监控的内存

4

WPM

Watchpoint Malloc 被监控的内存分配

4

WPN

Watchpoint Entry 被监控的内存

4

WPR

Watchpoint Read 被监控的内存读

4

WPW

Watchpoint Write 被监控的内存写

4

WPX

Watchpoint Exit 退出被监控的内存

4

ZPR

Zero Page Read 零页面读

1

ZPW

Zero Page Write 零页面写

1

 

1级:致命错误。   2级:危险错误。    3级:警告信息     4级:提示信息(非错误)

五、             文件描述符问题

在上面的内存问题表中,对于大多数的内存问题来说,相信对于熟悉C/C++的程序员,并不陌生。有一些关于Watchpoint和文件描述符的内容,可能会让你看得比较模糊,对于Watchpoint,我会在后面讲述。这一节,我就一个示例说一说文件描述述问题是如何产生的,并由此介绍一下Purify的一些特性。

 

先查看下面这段程序:

 

#include

 

main()

{

    FILE* fp;

    int num;

 

    fp = fopen("./test.txt", "r");

    if ( fp == NULL){

        perror("Error:");

        exit(-1);

    }

 

    fscanf(fp, "%d", &num);

    if ( num < 0 ){

       printf("Error: the num should be greater than 0!\n");

       exit(-1);

    }

 

    fclose(fp);

}

 

在当前目录下建一个test.txt的文件,并设置其内容为-20。使用Purify编译并运行程序:

>  purify gcc -g -o testfd testfd.c

Purify 2003.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2002 Rational Software Corp.  All rights reserved. 

Instrumenting: ccqqF6pY.o  Linking

 

>./testfd

 

出现以下画面:

 

 

由图中,我们可以看到,Purify报告有FIU错误,意思是,我们在程序退出时,没有关闭文件描述符。还有一些算是安全的文件描述符信息,那就是关于012这三个标准文件描述符的FIU,这些信息是正常的,所以在其前面也就没有小三角符号了。

 

通过这个例子,我们可以看到,Purify不但可以找到内存的操作错误,还可以找到文件描述符的错误。

 

如果你不想让Purify显示FIU信息,你可以设置Purify-fds-inuse-at-exit=no 选项,如:

 

>  purify –fds-inuse-at-exit gcc -g -o testfd testfd.c

 

或者使用PurifyAPI函数 purify_clear_fds_inuse 来阻止显示,你可以在你的程序中调用PurifyAPI函数。有关PurifyAPI函数的细节,我会在后面给你讲述。

 

阅读(659) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~