我目前面临的是我在团队正在开展的一个大型复杂项目中遇到过的最邪恶的错误之一.我们使用C++作为编程语言,目前使用Visual Studio进行开发,尽管最终产品旨在跨平台运行.
错误:
我们的系统中存在一个错误,它会在看似随机的执行点触发崩溃.崩溃原因通常是对每次执行程序时更改的地址的读取访问冲突.有时我们也会遇到堆损坏错误.调用堆栈引导我们在代码库中使用变量点,并且很少使用一些外部库(在我们的例子中为Lua),其中错误显然不存在.
好像这个bug在过去4个月里一直在发展.大概一段时间以前,我的一些团队成员看到前端程序在方式和位置上的崩溃与现在发生的情况非常相似.
更多细节:
我们的代码库大约有800K行的纯C++(评论除外)很大,并且是在3年的时间里开发的.目前的项目重约300K.我们使用了过多的单元测试和其他方法来消除错误,如断言,智能指针等.
其他人和我一直试图找到这个错误超过2周.对我来说,这不仅仅是一场噩梦.在这样一个复杂的项目中,即使是好的旧版printf调试也似乎在现在的复杂性方面失败了.
我的问题
我们在这面面有什么样的错误？有没有这个名字？这种错误是否会在其他大型项目中或多或少地发生？
在使用各种实用程序,各种平台和各种构建设置进行了2周的无果力调试后,我们可以做些什么来找到并消除它？
(我之前的问题已经结束,所以我这次试图更好地制定它并提供更多细节,链接:https://stackoverflow.com/questions/7154645/how-is-this-kind-of-bug-called)
您描述的症状是典型的堆损坏(并非所有堆损坏都会报告错误消息!).您需要审核程序中所有对象的生命周期; 确保你没有释放两次东西,或者在释放它们之后使用它们,并确保你没有溢出任何缓冲区.您可能希望借此机会使用std::smart_ptr(或boost::smart_ptr)等内容来自动执行堆管理的各个部分.
如果您使用的是Linux或Mac OS,请尝试在valgrind下运行程序- 它会检测到许多堆和堆栈损坏错误.在Windows上,使用应用程序验证程序 ; 它可以帮助使错误导致崩溃更接近真正发生的时刻.
如果您正在使用线程,则导致堆损坏的竞争条件是另一种可能性.审核您的锁定机制.
如果您可以轻松地重现此错误并拥有源控制系统,请考虑二分法以确定何时引入它.也就是说,对源代码历史记录执行二进制搜索,以找到第一个带有bug的提交.Git有一个自动执行此操作的工具 - git-bisect - 如果您还没有使用git,可以将存储库的副本导入git以运行此工具.
此外,查看是否可以禁用程序的某些部分(防止有问题的代码被调用)以尝试缩小问题范围.请注意,这可能有误报 - 如果您禁用模块X并且它停止崩溃,则可能意味着模块X正在破坏堆,或者它可能意味着模块W损坏了堆并且模块X恰好擅长注意到它.
| 归档时间： |
|
| 查看次数： |
138 次 |
| 最近记录： |