如何解决 " HEAP: Free Heap block xxxxxxxx modified at xxxxxxxx after it was freed "

Free Heap block xxxxxxxx modified at xxxxxxxx after it was freed 收藏

方法一:如果你是C++程序员,如果你写过一个很复杂的程序,如果你经常碰到莫名其妙的崩溃问题。那么你就有可能遭遇了野指针。如果你比 较细心,注意了Debug output输出窗口的话,那么你就有可能注意到这样一行提示:

HEAP:   Free   Heap   block   xxxxxxxx modified   at   xxxxxxxx after   it   was   freed

网络上关于这个问题提问的人不少,但是真正给的出答案的却少之又少。在网上搜索了几天,终于发现了这个问题的解决之道。下面我来介绍一下。

GFlags是windows debug tools 工具包下的一个工具,在Windows 2000的Resource Kit中也可以找得到。用来设置一些调试属性,总体上分为3个级别System, Kernel, 和 Image File。

我们设置好Path环境变量,将其指向Debug tools工具的目录下。

输入如下命令行:

gflags -p /enable test.exe /full /unaligned

或者 pageheap app.exe /full

该命令行会在注册表里设置一些调试参数,使内存在使用的时候加入了保护机制,所以一旦内存写越界,或者发生野指针的问题,都会导致一个中断。由此, 你就可以确定问题到底出在哪里了。

方法二:

多线程与内存(heap)

关于多线程中的内存问题,必需足够地重视,否则,程序总是会出现莫名其妙的错误。如果幻想某些情况“应该”不会出现,或者是认为某些步骤是按照正常 的顺序下来的,那就错误大大地,因为有一个简单的事实,就是你没有遵守事实,想和CPU对着干!

xx SDK的报错退出问题,从去年直到现在都没有得到有效的解决,近段时间,被频繁地爆露出来,是到了不得不直面的时候了,所以,前两周,去了xx N次,直到现在,还不能确定问题是否真地解决了

SDK的现象:
在自己的测试demo上没有问题,而在平台上就有问题
后来的测试证明,不是demo没有问题,而是原来的demo只 是在跑自己测试的设备,其数量少,环境不真实,实际的情况无法得到有效的测试,所以,demo不会有任何问题

直接运行程序,就是出现调试的那种错误,在平台的vc debug模式下,出现的是触发了用户断点的错误。在SDK的vc debug模式下,爆露了错误的本质:
HEAP[pingtai.exe]: HEAP: Free Heap block 2be3000 modified at 2be3200 after it was freed
这种错误过去从没有遇到过,经查,表明是因为堆被破坏而产生错 误。种种迹象表明,是因为某个内存被删除之后,其内容又被修改了,这样就是破坏了堆,就出现了这种错误,模拟程序如下:

void fun1()
{
char *p = new char[128];
delete[] p;

strcpy( p, "abcdefghijklmnopqrstuvwxyz" );
}

在我模拟的时候,其情况如下:
1. 如果我strcpy()的字节少于13个字节,则不会报任何错误。此情况并不绝对
2. 当fun1()返回时,并不出错,当程序退出时,报错
3. 在fun1()返回后,再调用其它任何函数,即会报错

为方便后面的叙述,把错误的描述如下:
HEAP[]: HEAP: Free Heap block modified at after it was freed

对模拟程序的报错进行分析,得出如下结论:
对内存进行了删除,然后,又修改了内存处 的内容,其中,是被包含在中的,形式如下:
|------------------------------|
| |            |
|------------------------------|
在 模拟程序中, = p, >= p 且 < p + 128
在真实的内存中,并不是等于p,而是会比p小,其不表示程序代码中的任何一个内存,而是在new时,用于保存p 的内存而产生的内存指针,该指针由windows保存和维护(注:个人认为,通过计算,应该是可以得到p的地址),实际的模式如下:
|------------------------------|
| | p                 |
|------------------------------|
是windows占用的内存,而p是程序占用的内存

既然内存的操作已经明确,而且也知道了如何产生了这种错误,那么就要根据来找是程序中哪个地方出现了这种情况,采用倒推 的方式,即首先根据找到是哪个内存被删除后又重新进行了附值(或者是其中的某处被重新附值),然后再根据情况来使删除和附值不 要冲突

程序的顺序应该没有问题,因为都是删除后就不再进行附值操作,或者是其它任何使用的可能了,所以,从需要分配内存(主要是char*类型的内存分 配)变量开始找起。把所有new出来的char*指针地址及其长度打印出来,从上万行的打印信息中一个一个查找,却发现没有
这 就奇怪了,难道是程序的执行顺序出现了问题?不可能吧
把所有new出来的类地址及其内存范围进行打印,再一行一行地仔细找,汗......
竟 然是CAccept类出现了这种情况!难道其删除之后,还有被使用的情况发生?根据以上内存的分析,肯定是有这种使用情况存在,否则....,找!
因 为CAccept的类使用较少,找起来也比较容易,主要就在两个地方使用,一个是完成端口的死循环中,一个是任务检查的死循环中,肯定是这两个地方的使用 有冲突。
完成端口的工作模式:
while( true )
{
if ( !getcompleteio() )
break;
if ( isaccept() )
{
CAccept *pacc = getaccept(); // 从列表中获取
// 使用pacc,其中有附值操作
... ...
// 删除pacc
SAFE_DELETE(pacc)
}
else
{
// 数据收发及socket端口的其它消息处理
}
}

任务检查的工作模式:
while ( true )
{
wait(5000); // 等待5秒钟,开始任务检查
lock();
while ( not_end_accept_list )
{
CAccept *pacc = nextaccept();
if ( pacc->tooLongTime )
SAFE_DELETE(pacc) // 删除 pacc
}
unlock();

// 连接检查
...
}

对accept的操作子函数(比如createaccept()、getaccept()、deleteaccept()等),都是被放入临界区中 的,这里仔细检查发现,完成端口中对CAccept的使用没有被放入临界区中,虽然其getaccept()中有临界区的操作,虽然任务检查中对 accept列表的操作也是在临界区中进行的,那么,问题肯定就是出现在了这里。为了验证,对任务检查处的accept删除和在完成端口中对accept 的使用进行信息打印,发现,当完成端口中还没有对其获取的CAccept使用完时,已经被任务检查的循环删除了!
这种情况在正常情况很难出现, 为 了使它容易出现,对临界区的操作加了延时,即人为使每个操作都等待较长的时间(原来是没有任何等待的),比如100毫秒,或者50毫秒等,这样,可以使很 多的操作都被挂起,在设备的连接达到一定多的时候,这种挂起的操作会越集越多,采用这种方法,可以使一些问题较容易地复现出来
找到问题了,解决 起 来应该是比较容易的了(有些可是棘手的,比如完成端口中else分支里的socket消息的处理),只需要在完成端口中把对CAccept的使用也放入相 应的临界区中即可,修改完毕,测试,再也没有CAccept的堆问题了,至此,该部分的问题已“完美”地被解决了,那个痛快啊---------,就别提 了... ...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
还 有两个问题,一个是关于上层对SDK的调用问题,一个是SDK内部的问题。
这两个问题,都和以上的问题的本质一样,就是删除了后还在使用!
1. 上层对SDK的调用
SDK 已经通知了上层设备断开,但是,上层在得到该消息之后,竟然还在调用相应的接口。这本身不成问题,因为上层调用SDK的时候,SDK会从相关的设备列表中 获取相应的连接,然后拿这个连接对设备进行操作,如果是该设备已经断开,那自然就会从相应的列表中删除掉,那么在上层调用的API中获取连接时,肯定是获 取失败,SDK在判断后,自然直接返回失败。没错!你说得太对了,就是这样。...... 停!你想,仔细地想一想,然后再往下看
================================
在 SDK中,不知道上层对SDK的调用和消息接收,是在一个线程中还是两个线程中,那么,SDK无从知道上层对SDK的消息处理和API调用的先后顺序,有 一种情况,应该是比较容易理解的,当SDK向上层进行了很多的消息通知,上层可能是会把这个消息放入消息队列中,然后一个一个地慢慢处理,其处理的某一个 消息,也许是10秒钟之前的消息(有点夸张),如果是这样,而且如果刚好这个消息就是连接断开的消息,那么在其处理该消息之前的3秒钟,用户要对该设备下 发命令,用户看到的结果就是,该设备在线,即下发命令失败,而且显示的错误消息是设备不在线!这样,程序也不会出错,因为7秒了,太久了,SDK应该是已 经把这个连接从连接列表中删除了。
但不幸的是,并不总是这种情况,而是有一个糟糕的情况可能会出现。当API函数中获取到相应的连接后,正在向 设 备下发命令时,连接列表被任务检查中的连接检查循环删除了(比如有1分钟都没有收到任何数据),这时,如果下发命令的函数中是读取,而不进行任何的附值操 作,则出现的错误,应该是内存非法读的异常,否则,出现的错误,应该是和上面一样的堆错误。这种错误,也许解决起来比较容易,比如在使用时,也放入临界 区,这样当然可行,只是当有100个API时,你就必需得进行100次临界区的操作,这不算重要,更重要的是,由于你在最外层增加了临界区的操作,那么在 SDK的内部,必需要小心地保证临界区的操作不会产生冲突,否则,就会发生程序无反应的情况,需要使用任务管理器来结束的后果。如果其中有附值操作,这也 许是唯一的一种解决方法,但如果是没有附值操作,则可能会比较简单,比如,我只在那时出现了这个错误的API外层,增加了 try...catch()...,这样,如果执行的中间其实例被删除了,则该API直接返回失败。具体的解决方案,可以根据实际情况的不同,进行不同的 处理,这里,只是阐明我自己的想法而已
2. SDK内部的另外一个问题
和CAccept完全一样,只是其复杂度相当大,由于其几乎涉及 到程序的所有地方,所以,解决起来相当棘手,而且,由于其和要上层通讯,则一不小心,就会使临界区冲突(除了上层的代码之外,SDK中的代码都被放入临界 区):
[收到socket消息] --> [通知上层] --> [上层调用SDK API] --> [API调用SDK内部的函数]
这个过程中,因为SDK通知上层后,需要等到上层返回,才进行下一步处理,上层需要调用API的返回后自己才返 回,而API调用内部函数时候,可能需要先进入临界区才能操作,如此便出现了临界区的冲突。
所以,在处理收到的socket消息时,被放入临界区 是比较危险的做法,所以,这里如果要找到一个好的解决方案,比较棘手

由于时间问题,暂只浅谈之.

你可能感兴趣的:(开发总结)