野指针产生的原因与避免方法、调试寻找野指针的方法

2012-07-19 0 条评论 12,254 次阅读 被赞了 2 次
目录
[隐藏]

“野指针”是代指指向的地址空间或变量无法进行结果预期，或者和原本的使用目的不同，导致程序出core或未按照设计预期运行的情况。“野指针”是很危险的，if无法判断一个指针是正常指针还是“野指针”。有个良好的编程习惯是避免“野指针”的唯一方法。

百度测试工程师面试题
百度测试工程师面试题

如果程序定义了一个指针，就必须要立即让它指向一个我们设定的空间或者把它设为NULL，如果没有这么做，那么这个指针里的内容是不可预知的，即不知道它指向内存中的哪个空间（即野指针），它有可能指向的是一个空白的内存区域，可能指向的是已经受保护的区域，甚至可能指向系统的关键内存，如果是那样就糟了，也许我们后面不小心对指针进行操作就有可能让系统出现紊乱，死机了。所以我们必须设定一个空间让指针指向它，或者把指针设为NULL。

这是怎么样的一个原理呢，如果是建立一个与指针相同类型的空间，实际上是在内存中的空白区域中开辟了这么一个受保护的内存空间，然后用指针来指向它，那么指针里的地址就是这个受保护空间的地址，而不是不可预知的了，然后我们就可以通过指针对这个空间进行相应的操作。

如果我们把指针设为NULL，我们在头文件定义中的 #define NULL 0 可以知道，其实NULL就是表示0，那么我们让指针＝NULL，实际上就是让指针＝0，如此，指针里的地址（机器数）就被初始化为0了，而内存中地址为0的内存空间……不用多说也能想象吧，这个地址是特定的，那么也就不是不可预知的在内存中乱指一气的野指针了。

还应该注意的是，free和delete只是把指针所指的内存给释放掉，但并没有把指针本身干掉。指针p被free以后其地址仍然不变（非NULL），只是该地址对应的内存是垃圾，p成了“野指针”。如果此时不把p设置为NULL，会让人误以为p是个合法的指针。用free或delete释放了内存之后，就应立即将指针设置为NULL，防止产生“野指针”。内存被释放了，并不表示指针会消亡或者成了NULL指针。（而且，指针消亡了，也并不表示它所指的内存会被自动释放。）

野指针的成因

1、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的默认值是随机的，它会乱指一气。
2、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。
3、指针操作超越了变量的作用范围。这种情况让人防不胜防。

野指针的避免-正确使用指针

野指针出现了就是程序有问题，它在程序里是不能做任何判定的，所以只能避免

通常避免野指针的办法是正确的使用指针  

1.声明一个pointer的时候注意初始化为null  

int*   pInt   =   NULL;  

2.分配完内存以后注意ASSERT

pInt   =   new   int[num];  
ASSERT(pInt   !=   NULL);  

3.删除时候注意用对操作符

对于new   int类型的，用delete  
对于new   int[]类型的，用delete   []  

4.删除完毕以后记得给他null地址

delete   []   pInt;  
pInt   =   NULL;  

5.记住，谁分配的谁回收，不要再一个函数里面分配local   pointer，送到另外一个函数去delete  

6.返回local   address是非常危险的，如必须这样做，请写注释到程序里面，免得忘记 

寻找“野指针”

　　本文介绍了一种在调试过程中寻找悬挂指针（野指针）的方法，这种方法是通过对new和delete运算符的重载来实现的。

　　这种方法不是完美的，它是以调试期的内存泄露为代价来实现的，因为文中出现的代码是绝不能出现在一个最终发布的软件产品中的，只能在调试时使用。

　　在VC中，在调试环境下，可以简单的通过把new替换成DEBUG_NEW来实现功能更强更方便的指针检测，详情可参考MSDN。DEBUG_NEW的实现思路与本文有相通的地方，因此文章中介绍的方法虽然不是最佳的，但还算实用，更重要的是，它提供给我们一种新的思路。

简介：

　　前几天发生了这样一件事，我正在调试一个程序，这个程序用了一大堆乱七八糟的指针来处理一个链表，最终在一个指向链表结点的指针上出了问题。我们预计它应当指向的是一个虚基类的对象。我想到第一个问题是：指针所指的地方真的有一个对象吗？出问题的指针值可以被4整除，并且不是NULL的，所以可以断定它曾经是一个有效的指针。通过使用Visual Studio的内存查看窗口（View->Debug Windows->Memory）我们发现这个指针所指的数据是FE EE FE EE FE EE …这通常意味着内存是曾经是被分配了的，但现在却处于一种未分配的状态。不知是谁、在什么地方把我的指针所指的内存区域给释放掉了。我想要找出一种方案来查出我的数据到底是怎么会被释放的。

背景：

　　我最终通过重载了new和delete运算符找到了我丢失的数据。当一个函数被调用时，参数会首先被压到栈上后，然后返回地址也会被压到栈上。我们可以在new和delete运算符的函数中把这些信息从栈上提取出来，帮助我们调试程序。

代码：

　　在经历了几次错误的猜测后，我决定求助于重载new和delete运算符来帮我找到我的指针所指向的数据。下面的new运算符的实现把返回地址从栈上提了出来。这个返回地址位于传递过来的参数和第一个局部变量的地址之间。编译器的设置、调用函数的方法、计算机的体系结构都会引响到这个返回地址的实际位置，所以您在使用下面代码的时候，要根据您的实际情况做一些调整。一旦new运算符获得了返回地址，它就在将要实际分配的内存前面分配额外的16个字节的空间来存放这个返回地址和实际的分配的内存大小，并且把实际要分配的内存块首地址返回。

　　对于delete运算符，你可以看到，它不再释放空间。它用与new同样的方法把返回地址提取出来，写到实际分配空间大小的后面（译者注：就是上面分配的16个字节的第9到第12个字节），在最后四个字节中填上DE AD BE EF（译者注：四个十六进制数，当成单词来看正好是dead beef，用来表示内存已释放真是很形象！），并且把剩余的空间（译者注：就是原本实际应该分配而现在应该要释放掉的空间）都填上一个重复的值。

　　现在，如果程序由于一个错误的指针而出错，我只需打开内存查看窗口，找到出错的指针所指的地方，再往前找16个字节。这里的值就是调用new运算符的地址，接下来四个字节就是实际分配的内存大小，第三个四个字节是调用delete运算符的地址，最后四个字节应该是DE AD BE EF。接下的实际分配过的内存内容应该是77 77 77 77。

　　要通过这两个返回地址在源程序中分别找到对应的new和delete，可以这样做：首先把表示地址的四个字节的内容倒序排一下，这样才能得到真正的地址，这里因为在Intel平台上字节序是低位在前的。下一步，在源代码上右击点击，选“Go To Diassembly”。在反汇编的窗口上的左边一栏就是机器代码对应的内存地址。按Ctrl + G或选择Edit->Go To…并输入你找到的地址之一。反汇编的窗口就将滚动到对应的new或delete的函数调用位置。要回到源程序只需再次右键单击，选择“Go To Source”。您就可以看到相应的new或delete的调用了。

　　现在您就可以很方便的找出您的数据是何时丢失的了。至于要找出为什么delete会被调用，就要靠您自己了。

C++代码
  1. 　　#include <MALLOC.H>   
  2. 　　void * ::operator new(size_t size)   
  3. 　　{   
  4. 　　　　int stackVar;   
  5. 　　　　unsigned long stackVarAddr = (unsigned long)&stackVar;   
  6. 　　　　unsigned long argAddr = (unsigned long)&size;   
  7. 　　　　void ** retAddrAddr = (void **)(stackVarAddr/2 + argAddr/2 + 2);   
  8. 　　　　void * retAddr = * retAddrAddr;   
  9. 　　　　unsigned char *retBuffer = (unsigned char*)malloc(size + 16);   
  10. 　　　　memset(retBuffer, 0, 16);   
  11. 　　　　memcpy(retBuffer, &retAddr, sizeof(retAddr));   
  12. 　　　　memcpy(retBuffer + 4, &size, sizeof(size));   
  13. 　　　　return retBuffer + 16;   
  14. 　　}   
  15. 　　void ::operator delete(void *buf)   
  16. 　　{   
  17. 　　　　int stackVar;   
  18. 　　　　if(!buf)   
  19. 　　　　　　return;   
  20. 　　　　unsigned long stackVarAddr = (unsigned long)&stackVar;   
  21. 　　　　unsigned long argAddr = (unsigned long)&buf;   
  22. 　　　　void ** retAddrAddr = (void **)(stackVarAddr/2 + argAddr/2 + 2);   
  23. 　　　　void * retAddr = * retAddrAddr;   
  24. 　　　　unsigned char* buf2 = (unsigned char*)buf;   
  25. 　　　　buf2 -= 8;   
  26. 　　　　memcpy(buf2, &retAddr, sizeof(retAddr));   
  27. 　　　　size_t size;   
  28. 　　　　buf2 -= 4;   
  29. 　　　　memcpy(&size, buf2, sizeof(buf2));   
  30. 　　　　buf2 += 8;   
  31. 　　　　buf2[0] = 0xde;   
  32. 　　　　buf2[1] = 0xad;   
  33. 　　　　buf2[2] = 0xbe;   
  34. 　　　　buf2[3] = 0xef;   
  35. 　　　　   
  36. 　　　　buf2 += 4;   
  37. 　　　　memset(buf2, 0x7777, size);   
  38. 　　　　// deallocating destroys saved addresses, so don't   
  39. 　　　　// buf -= 16;   
  40. 　　　　// free(buf);   
  41. 　　}  

其它值得关注的地方：

　　这段代码同样可以用于内存泄露的检测。只需修改delete运算符使它真正的去释放内存，并且在程序退出前，用__heapwalk遍历所有已分配的内存块并把调用new的地址提取出来，这就将得到一份没有被delete匹配的new调用列表。

　　还要注意的是：这里列出的代码只能在调试的时候去使用，如果你把它段代码放到最终的产品中，会导致程序运行时内存被大量的消耗。

参考：

http://www.cnitblog.com/mantou/archive/2005/10/07/3107.html
http://www.cppblog.com/sunraiing9/archive/2006/12/13/16379.aspx
调试过程中寻找野指针（百度文库）
http://wenku.baidu.com/view/6d86b04f2e3f5727a5e962b1.html
http://www.cnblogs.com/yc_sunniwell/archive/2010/06/28/1766854.html

相关文章:

Default Thumbnailvisual c++ 6.0中关于音乐文件路径设置问题 Default Thumbnailsplit函数分割字符串的几种方法 Default ThumbnailC++中cin.clear() 和 cin.sync() 的使用区别
点赞 (2)
知识共享许可协议
本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

Captcha Code