引用第22楼xtfllbl于2009-12-09 17:15发表的 :
忘记说了,那位开发和工程环境挂的那位,电脑里带qq的全删掉,只留下代Q的
就是我啦。。。
我的程序挂的时候,部分现象与楼主的相似~
特点是
1\时而出问题,时而不出问题~~
2\工程环境处问题,开发环境从未出问题 -- 对这点我一直都比较迷惑,而且我也在开发环境,以容易引起程序挂的操作做了很多的测试,仍未使程序挂掉过~
3、调试会出问题~
经过两周痛苦的代码检查、尝试、试验,初步认定是由一个隐秘很深的越界造成的。
将相关经验和你们分享。
主程序调用了 a.dll, b.dll, c.dll, d.dll ,
CB b;
CC c;
CD d;
int main()
{
CA a; //1
a.func();//2
printf("end of main");
}
程序是在析构的时候出了问题, b.dll, c.dll, d.dll 是经过长时间运行考验过的, a.dll是与主程序相关,我自己维护的。
由于调试的时候总是导致VS挂掉, 为了检查是哪个模块析构的时候出了问题,便在1、2句 加了大括号,如下:
int main()
{
{
CA a; //1
a.func();//2
}
printf("end of main");
}
程序运行,每次都能打印"end of main", 这说明模块a正常析构了~ 便把问题定位到全局变量~
后来通过在析构函数加打印语句的方法,找出模块c析构出问题~! 但是c出问题的地方在一个map::clear()的时候,而且,事实上程序已经将有关对c模块调用的部分注释了~~
仔细检查了c的代码,没发现有什么问题~
这个时候就非常痛苦了~~~ 通过调试找不到准确的位置
接下来,只有通过大量随机的操作来重现问题,总结最简的操作~~ 找出最有可能出错的地方~
后来发现,虽然每次都是c析构的时候出问题,但是真正的问题却发生在模块a里! 这也是最初根据析构出了问题,加大括号定位的时候给忽略了~
实际上,a模块里隐藏了一个越界的问题,但是a析构的时候没报错~~ a的越界导致非法修改了c的数据,导致c析构的时候出问题~!
这真是次极其艰苦的查找过程~
[ 此帖被stdjgwyc在2009-12-11 10:48重新编辑 ]