引用第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重新编辑 ]
