现在的位置: 首页 > 综合 > 正文

常见的内存错误

2013年03月06日 ⁄ 综合 ⁄ 共 4597字 ⁄ 字号 评论关闭

1    内存泄露

大家都知道,在堆上分配的内存,如果不再使用了,应该把它释放掉,以便后面其它地方可以重用。在C/C++中,内存管理器不会帮我们自动回收不再使用的内存。如果忘了释放不再使用的内存,这些内存就不能被重用,就造成了所谓的内存泄露。

 

它是最为常见的一类错误。一两处内存泄露通常不至于让程序崩溃,也不会出现逻辑上的错误,加上进程退出时,系统会自动释放该进程所有相关的内存,所以内存泄露的后果相对来说还是比较温和的。当然了,量变会产生质变,一旦内存泄露过多以致于耗尽内存,后续内存分配将会失败,程序可能因此而崩溃。

 

现在的PC机内存够大了,加上进程有独立的内存空间,对于一些小程序来说,内存泄露已经不是太大的威胁。但对于大型软件,特别是长时间运行的软件,或者嵌入式系统来说,内存泄露仍然是致命的因素之一。

 

2.   内存越界访问

内存越界访问有两种:一种是读越界,即读了不属于自己的数据,如果所读的内存地址是无效的,程度立刻就崩溃了。如果所读内存地址是有效的,在读的时候不会出问题,但由于读到的数据是随机的,它会产生不可预料的后果。另外一种是写越界,又叫缓冲区溢出。所写入的数据对别人来说是随机的,它也会产生不可预料的后果。

 

内存越界访问造成的后果非常严重,是程序稳定性的致命威胁之一。更麻烦的是,它造成的后果是随机的,表现出来的症状和时机也是随机的,让BUG的现象和本质看似没有什么联系,这给BUG的定位带来极大的困难。

 

一 些工具可以够帮助检查内存越界访问的问题,但也不能太依赖于工具。内存越界访问通常是动态出现的,即依赖于测试数据,在极端的情况下才会出现,除非精心设计测试数据,工具也无能为力。工具本身也有一些限制,甚至在一些大型项目中,工具变得完全不可用。比较保险的方法还是在编程是就小心,特别是对于外部传入 的参数要仔细检查。

 

3.    野指针

野指针是指那些我们已经释放掉的内存指针。当调用free(p)时, p指向的内存被释放了,p本身没有变化,它指向的内存仍然是有效的,继续读写p指向的内存,没有人能拦得住。

 

释放掉的内存会被内存管理器重新分配,此时,野指针指向的内存已经被赋予新的意义。对野指针指向内存的访问,无论是有意还是无意的,都为此会付出巨大代价,因为它造成的后果,如同越界访问一样是不可预料的。

 

释放内存后立即把对应指针置为空值,这是避免野指针常用的方法。这个方法简单有效,只是要注意,当然指针是从函数外层传入的时,在函数内把指针置为空值,对外层的指针没有影响。比如,在析构函数里把this指针置为空值,没有任何效果,这时应该在函数外层把指针置为空值。

 

4.   访问空指针

空指针在C/C++中占有特殊的地址,通常用来判断一个指针的有效性。空指针一般定义为0。现代操作系统都会保留从0开始的一块内存,至于这块内存有多大,视不同的操作系统而定。一旦程序试图访问这块内存,系统就会触发一个异常。

 

操作系统为什么要保留一块内存,而不是仅仅保留一个字节的内存呢?原因是:一般内存管理都是按页进行管理的,无法单纯保留一个字节,至少要保留一个页面。保留一块内存也有额外的好处,可以检查诸如p=NULL; p[1]之类的内存错误。

 

在一些嵌入式系统中,从0开始的一块内存是用来安装中断向量的,没有MMU的保护,直接访问这块内存好像不会引发异常。不过这块内存是代码段的,不是程序中有效的变量地址,所以用空指针来判断指针的有效性仍然可行。

 

在访问指针指向的内存时,在确保指针不是空指针。访问空指针指向的内存,通常会导致程度崩溃,或者不可预料的错误。

 

5.   引用未初始化的变量

未初始化变量的内容是随机的(VC一类的编译器会把它们初始化为固定值,如0xcc),使用这些数据会造成不可预料的后果,调试这样的BUG也是非常困难的。

 

对于态度严谨的程度员来说,防止这类BUG非常容易。在声明变量时就对它进行初始化,是一个编程的好习惯。另外也要重视编译器的警告信息,发现有引用未初始化的变量,立即修改过来。

 

6.   不清楚指针运算

对于一些新手来说,指针常常让他们犯糊涂。 

比如int *p = …; p+1等于(size_t)p + 1

事实上, p+n 等于 (size_t)p + n * sizeof(*p)

 

指针是C/C++中最有力的武器,功能非常强大,无论是变量指针还是函数指针,都应该掌握都非常熟练。

 

7.    结构的成员顺序变化引发的错误

在初始化一个结构时,一般一个成员一个成员的为结构初始化,若采用快捷方式,如:

Structs

{

    int   l;

    char* p;

};

 

intmain(intargc, char* argv[])

{

    structss1 = {4, "abcd"};

    return 0;

以上这种方式是非常危险的,原因在于我们对结构的内存布局作了假设。如果这个结构是第三方提供的,它很可能调整结构中成员的相对位置。而这样的调整往往不会在文档中说明,我们自然很少去关注。如果调整的两个成员具有相同数据类型,编译时不会有任何警告,而程序的逻辑上可能相距十万八千里了。

 

正确的初始化方法应该是(当然,一个成员一个成员的初始化也行):

structs

{

    int   l;

    char* p;

};

 

intmain(intargc, char* argv[])

{

    structss1 = {.l=4, .p = "abcd"};

    structss2 = {l:4, p:"abcd"};

 

    return 0;

}

 

8.    结构的大小变化引发的错误

看看下面这个例子:

structbase

{

    intn;

};

 

structs

{

    structbaseb;

    intm;

};

 

OOP中,可以认为第二个结构继承了第一结构,这有什么问题吗?当然没有,这是C语言中实现继承的基本手法。

 

现在假设第一个结构是第三方提供的,第二个结构是你自己的。第三方提供的库是以DLL方式分发的,DLL最大好处在于可以独立替换。但随着软件的进化,问题可能就来了。

 

当第三方在第一个结构中增加了一个新的成员int k;,编译好后把DLL给我们,我们直接给了客户。程序加载时不会有任何问题,在运行逻辑可能完全改变!原因是两个结构的内存布局重叠了。解决这类错误的唯一办法就是全部重新相关的代码。

 

解决这类错误的唯一办法就是重新编译全部代码。由此看来,DLL并不见得可以动态替换。

      

9.    分配/释放不配对

大家都知道malloc要和free配对使用,new要和delete/delete[]配对使用,重载了类new操作,应该同时重载类的delete/delete[]操作。这些都是反复强调过的,除非当时晕了头,一般不会犯这样的低级错误。

 

而有时候我们却被蒙在鼓里,两个代码看起来都是调用的free函数,实际上却调用了不同的实现。比如在Win32下,调试版与发布版,单线程与多线程是不同的运行时库,不同的运行时库使用的是不同的内存管理器。一不小心链接错了库,那就麻烦了。程序可能动则崩溃,原因在于在一个内存管理器中分配的内存,在另外一个内存管理器中释放时出现了问题。

 

10.  返回指向临时变量的指针

栈里面的变量都是临时的。当前函数执行完成时,相关的临时变量和参数都被清除了。不能把指向这些临时变量的指针返回给调用者,这样的指针指向的数据是随机的,会给程序造成不可预料的后果。 

下面是个错误的例子:

char* get_str(void)

{

    Char str[] = {"abcd"};

 

    return str;

}

 

int main(int argc, char* argv[])

{

    char* p = get_str();

    printf("%s/n", p);

 

    return 0;

}

下面这个例子没有问题,

char* get_str(void)

{

    char* str = {"abcd"};

 

    return str;

}

 

Int main(intargc, char* argv[])

{

    char* p = get_str();

   printf("%s/n", p);

 

    return 0;

}

 

11.   试图修改常量

在函数参数前加上const修饰符,只是给编译器做类型检查用的,编译器禁止修改这样的变量。但这并不是强制的,完全可以用强制类型转换绕过去,一般也不会出什么错。

 

而全局常量和字符串,用强制类型转换绕过去,运行时仍然会出错。原因在于它们是是放在.rodata里面的,而.rodata内存页面是不能修改的。试图对它们修改,会引发内存错误。

 下面这个程序在运行时会出错:

Int main(intargc, char* argv[])

{

    char* p = "abcd";

    *p = '1';

 

    return 0;

}

 

12.   误解传值与传引用

C/C++中,参数默认传递方式是传值的,即在参数入栈时被拷贝一份。在函数里修改这些参数,不会影响外面的调用者。如:

#include <stdlib.h>

#include <stdio.h>

 

void get_str(char* p)

{

    p = malloc(sizeof("abcd"));

    strcpy(p, "abcd");

 

    return;

}

 

int main(int argc, char* argv[])

{

    char* p = NULL;

    get_str(p);

    printf("p=%p/n", p);

 

    return 0;

main函数里,p的值仍然是空值。

 

13.    重名符号

无论是函数名还是变量名,如果在不同的作用范围内重名,自然没有问题。但如果两个符号的作用域有交集,如全局变量和局部变量,全局变量与全局变量之间,重名的现象一定要坚决避免。gcc有一些隐式规则来决定处理同名变量的方式,编译时可能没有任何警告和错误,但结果通常并非所期望的。

 

下面例子编译时就没有警告:

t.c

#include <stdlib.h>

#include <stdio.h>

intcount = 0;

 

int get_count(void)

{

    Return count;

}

 

main.c

#include <stdio.h>

extern int get_count(void);

int count;

 

int main(int argc, char* argv[])

{

    count = 10;

    printf("get_count=%d/n", get_count());

 

    return 0;

如果把main.c中的int count;修改为int count = 0;gcc就会编辑出错,说multiple definition of `count'。它的隐式规则比较奇妙,所以还是不要依赖它为好。

 

14.     栈溢出

PC上,普通线程的栈空间也有十几M,通常够用了,定义大一点的临时变量不会有什么问题。

 

而在一些嵌入式中,线程的栈空间可能只5K大小,甚至小到只有256个字节。在这样的平台中,栈溢出是最常用的错误之一。在编程时应该清楚自己平台的限制,避免栈溢出的可能。

 

15.     误用sizeof

尽管C/C++通常是按值传递参数,而数组则是例外,在传递数组参数时,数组退化为指针(即按引用传递),用sizeof是无法取得数组的大小的。

 

抱歉!评论已关闭.