【问题标题】:Describing and finding a state-corrupting bug which causes seemingly random crashes描述并找到一个导致看似随机崩溃的状态破坏错误
【发布时间】:2011-11-01 13:30:04
【问题描述】:

在我的团队正在开展的一个大型复杂项目中,我目前正面临着我曾经遇到过的最邪恶的错误之一。我们使用 C++ 作为编程语言,目前使用 Visual Studio 进行开发,尽管最终产品旨在跨平台运行。

错误:

我们的系统中有一个错误会在看似随机的执行点触发崩溃。崩溃的原因通常是每次执行程序时都会更改地址的读取访问冲突。有时我们也会遇到堆损坏错误。调用堆栈将我们引向代码库中的不同点,而很少引向某些外部库(在我们的例子中是 Lua),这些错误显然不存在。

似乎这个错误在过去 4 个月里一直在发展。在那段时间之前,大致上,我的一些团队成员看到前端程序崩溃的方式和位置与现在非常相似。

更多细节:

我们的代码库大约有 800K 行纯 C++(不包括 cmets),开发时间为 3 年。 当前项目重约 300K。我们之前使用过过多的单元测试和其他方法来消除错误,例如断言、智能指针等。

我和其他人已经尝试找到这个错误超过 2 周了。对我来说,这不仅仅是一场噩梦。在这样一个复杂的项目中,面对现在的复杂性,即使是好的旧 printf 调试似乎也失败了。

我的问题

  • 我们在这里面临什么样的错误?甚至有这个名字吗?这种错误在其他大型项目中是否经常发生?

  • 在使用各种实用程序、在各种平台和各种构建设置上进行了 2 周的无果调试后,我们可以做些什么来找到并消除它?

(我之前的问题已经结束,所以这次我试图更好地表述它并提供更多细节,链接:https://stackoverflow.com/questions/7154645/how-is-this-kind-of-bug-called

【问题讨论】:

  • Arf,零星的错误是最糟糕的。是时候学习使用调试工具了。

标签: c++ debugging


【解决方案1】:

您描述的症状是堆损坏的典型症状(并非所有堆损坏都报告为带有错误消息!)。您将需要审核程序中所有对象的生命周期;确保你没有两次释放东西,或者在释放它们之后使用它们,并确保你没有溢出任何缓冲区。您可能想借此机会使用诸如std::smart_ptr(或boost::smart_ptr)之类的东西来自动化您的部分堆管理。

如果您使用的是 Linux 或 Mac OS,请尝试在 valgrind 下运行您的程序 - 它会检测到许多堆和堆栈损坏错误。在 Windows 上,使用 application verifier;它可以帮助使错误导致崩溃更接近真正发生的时间点。

如果您使用线程,导致堆损坏的竞争条件是另一种可能性。还要审核您的锁定机制。

如果您可以轻松重现此错误,并且有适当的源代码控制系统,请考虑一分为二来确定它的确切引入时间。也就是说,对您的源代码历史记录执行二进制搜索以找到第一个带有错误的提交。 Git 有一个自动执行此操作的工具 - git-bisect - 如果您尚未使用 git,您可以将存储库的副本导入 git 以运行此工具。

另外,请查看您是否可以禁用程序的某些部分(完全阻止调用相关代码)以尝试缩小问题范围。请注意,这可能会产生误报 - 如果您禁用模块 X 并且它停止崩溃,则可能意味着模块 X 正在破坏堆,或者可能意味着模块 W 破坏了堆,而模块 X 恰好善于注意到它.

【讨论】:

  • 非常好的点。但请注意,将零星的错误一分为二非常困难。
  • @Owen,因此“如果你可以轻松复制”...:/
【解决方案2】:

只是补充了 Bdonlan 的出色答案:由于您正在为 Windows 开发代码并处理大型项目,我强烈建议您购买“高级 Windows 调试”一书并熟悉 WinDbg、AppVerifier 和其他类似工具。这将是非常值得的投资。 在本书中,有一整章专门讨论堆损坏(如上一个答案中已经提到的),这很可能是您面临的问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-06-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-07-21
    • 1970-01-01
    • 1970-01-01
    • 2014-04-11
    相关资源
    最近更新 更多