为什么某些事情永远不会崩溃调试器？

Question

我的应用程序使用GLUTesselator来镶嵌复杂的凹多边形。它在我运行普通版本的exe时会随机崩溃，但如果我在VS中开始调试，它永远不会崩溃。我发现这里这个权利这基本上是我的问题：

The multi-thread debug CRT (/MTd) masks the problem, because, like 

Windows并通过 调试器产生的进程，它提供给你的 程序的调试堆，这是 初始化为0XCD模式。 可能在某处使用 未初始化的内存区域作为指针从 堆中取消引用 它;与这两个调试堆你 离开它由于某种原因（也许 因为地址0xbaadf00d和 0xcdcdcdcd还有的有效分配 内存），但与“正常”堆 （也就是常初始化为0）你 得到一个访问冲突，因为你取消引用一个空指针 。

问题是在GLU32.dll发生崩溃，我无法找出为什么它有时试图解引用空指针。当我的多边形变得相当大并且有很多点时，它似乎会这样做。我能做什么？

谢谢

Answer 1

这是一个生活中的事实，有时程序在调试器中的行为有所不同。在你的情况下，一些内存的初始化方式不同，它的布局也可能不同。并发程序中的另一个常见情况是时序不同，并且调试器中竞争条件通常不经常发生。

您可以尝试手动将堆初始化为不同的值（或者查看Visual Studio中是否有此选项）。通常初始化为非零捕获更多的错误，但在你的情况下可能不是这种情况。您也可以尝试使用您的程序的内存映射来安排页面0xcdcdc000未映射。你可以试试这个（它可能会使程序的运行速度远远超过一个可变的断点）。在这种情况下，Visual Studio可以设置一个访问特定内存地址的断点。

Answer 2

但它从不崩溃，如果我开始在VS中调试。

嗯，我不知道确切为什么但同时在Visual Studio程序调试有时可以访问，将使其崩溃没有调试某些内存区域脱身。但我不知道确切的原因，但有时0xcdcdcdcd和0xbaadfood与此无关。它只是访问某些地址不会导致问题。发生这种情况时，您需要找到猜测问题的其他方法。

我该怎么办？

可能的解决方案：

1. 在程序安装异常处理程序（_set_se_translator，如果我没有记错）。访问冲突请尝试MinidumpWriteDump。稍后使用Visual Studio进行调试（afaik，崩溃转储调试在快速版本中不适用）或使用windbg。
2. 使用即时调试器。非快速版的视觉工作室具有此功能。可能有其他选择。
3. 编写自定义的内存管理器（即会覆盖新/删除，并会提供的malloc /免费的替代品（如果你使用它们）），将攫取大块的内存，锁定与VirtualProtect所有未使用的内存。在这种情况下，即使在调试模式下，所有无效访问都会导致崩溃。这种内存管理器需要大量内存，因为要被锁定，每个块应该与页面对齐。
4. 为所有可疑的函数调用添加过多的日志记录。将大量文本/调试信息转储到文件（或stderr）中 - 参数值，数组，您怀疑可能与崩溃相关的所有内容，在每次写入文件后刷新，否则在崩溃过程中会丢失一些信息。这样你就可以猜测程序崩溃之前发生了什么。
5. 尝试调试版本构建。如果在项目设置中为发布版本启用“调试信息”，您应该可以在某种程度上做到这一点。
6. 尝试在项目属性（configuration properties->c/c++->code genration）中打开/关闭“基本运行时检查”和“缓冲区安全检查”。
7. 尝试寻找某种外部工具 - 例如valgrind或bounds checker。尽管如此，就我的预测而言，＃3比这种方法更可靠。虽然这真的取决于问题。

Answer 3

链接到一个较早的问题，两种思想。

首先，你可能想看看以前question有关Valgrind的替代窗户。很多关于程序的提示都会帮助你。

现在的想法：

1）调试器可以从正在测试的代码崩溃停止你的程序，但它不解决问题。最糟糕的情况是，你只能在街上踢球，但仍然存在腐败现象，但从运行方式上看并不明显。当您发货时，您可以放心，有人会再次遇到问题。

2）经常发生在这样的情况下，什么是错误不是发生问题近。虽然您可能会注意到GLU32.dll中的问题，但可能是之前可能发生了损坏，甚至可能是在不同的线程或函数中，这并不会导致问题，并且在稍后的某个时间点程序会返回到损坏的区域并失败。