我有一个工作区，用于在一个循环中运行H.263视频编码器31次，即主程序被执行31次以生成31个不同的编码位流。此MS Visual Studio 2005工作区具有所有C源文件。当我为工作空间创建"调试"配置并构建并执行该配置时，它运行良好，即按预期生成了所有31个输出文件。
但是，当我将工作空间的配置设置为" RELEASE" mdoe，并重复该过程时，编码器在某些测试用例运行时崩溃。

现在进行调试，已通过以下验证：

• 分析代码以查看编码器的每次运行中是否遗漏了任何变量初始化
• 在两种模式(调试和释放)中都检查了各种工作区(解决方案)选项。

有一些明显的区别，但是我在两种模式下都将与优化相关的选项明确设为相同。

但是仍然无法解决问题并找到解决办法。有指针吗？

-阿吉特

解决方案

回答

我们确定没有预编译指令，例如，在Release模式下忽略一些非常重要的代码，但在Debug中允许它们吗？

另外，我们是否实施了任何可能指出引发错误的精确程序集的日志记录？

回答

如果不仔细检查代码，很难说出问题出在哪里。然而...

调试版本与发行版本之间的区别之一是如何设置函数调用堆栈框架。我们可以执行某些类的坏事(例如，使用错误数量的参数调用函数)，这些类在调试版本中不是致命的，而在发行版本中则严重崩溃。也许我们可以尝试将发行版中与堆栈框架相关的选项(抱歉，我忘了它们的名字)更改为与调试版相同的选项，然后查看是否有帮助。

另一件事可能是启用所有可能的警告，并修复所有警告。

回答

可能是两个线程的并发问题。 DEBUG配置减慢了执行速度，因此不会发生此问题。但是，仅是一个猜测。

回答

有趣的问题。我们确定没有潜伏在发布模式下的条件编译代码吗？ IE：

#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif

那是我真正想到的唯一一件事。

回答

如果崩溃是在测试案例中，我将更详细地研究崩溃，那么听起来很容易重现，这通常是大多数挑战。

回答

我们是否可以将调试符号添加到发布版本中，并在调试器中运行它，以查看崩溃的原因和原因？

回答

要考虑的另一件事：在调试模式下，变量使用0xCCCCCCCC而不是零进行初始化。那可能会有一些讨厌的副作用。

回答

是的，那些混蛋的死机是最难修复的。幸运的是，我们可以执行一些步骤，在我们手动查看代码并希望找到答案之前，会给我们一些提示。

什么时候崩溃？在每次测试中？在特定测试中？那个测试没有其他测试呢？

怎么了如果是访问冲突，是否有发生这种情况的模式？如果地址很低，则可能意味着某个地方存在未初始化的指针。

程序是否在调试配置下崩溃但没有连接调试器？如果是这样，正如John Smithers指出的，这很可能是线程同步问题。

我们是否尝试过通过Purify等分析器运行代码？它很慢，但是通常值得等待。

无论如何，请尝试调试发行版配置。它只会转储程序集，但仍可以指示发生了什么，例如代码指针跳到垃圾堆中间还是在外部库中遇到了断点。

我们使用的是英特尔架构吗？如果不是，请注意内存对齐错误，它们会在某些体系结构上崩溃而不会发出警告，并且由于过度优化，这些编解码器算法往往会造成很多情况。