我有一个工作区，用于在循环中运行 H.263 视频编码器 31 次，即 main 执行 31 次以生成 31 个不同的编码比特流。此 MS Visual Studio 2005 工作区包含所有 C 源文件。当我为工作区创建“调试”配置并构建和执行它时，它运行良好，即它按预期生成所有 31 个输出文件。 但是当我将工作区的配置设置为“RELEASE”mdoe 并重复该过程时，编码器在某些测试用例运行时崩溃。
现在要调试，验证如下：
有一些明显的差异，但我将优化相关选项在两种模式下明确相同。
但仍然无法确定问题并找到解决方法。有什么指点吗？
-阿吉特。
【问题讨论】：
如果不仔细检查代码，很难说出问题所在。不过……
调试版本和发布版本之间的区别之一是函数调用堆栈框架的设置方式。您可以做某些类型的坏事（例如调用具有错误数量的参数的函数），它们在调试版本中不是致命的，但在发布版本中会严重崩溃。也许您可以尝试将发布版本中与堆栈框架相关的选项（我忘记它们的名称，抱歉）更改为与调试版本相同，看看是否有帮助。
另一件事可能是启用所有可能的警告，并修复它们。
【讨论】：
可能是两个线程的并发问题。 DEBUG 配置会减慢执行速度，因此不会出现问题。但是，只是猜测。
【讨论】：
有趣的问题.. 你确定你没有潜伏的条件编译代码不是在发布模式下编译的吗？即：
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
这是我唯一能真正想到的......我自己从来没有经历过这样的事情......
【讨论】：
您能否将调试符号添加到发布版本并在调试器中运行以查看崩溃的位置和原因？
【讨论】：
是的，那些混蛋崩溃是最难修复的。幸运的是，在您求助于手动查看代码并希望找到针头之前，您可以执行一些步骤来为您提供线索。
什么时候崩溃？每次考试？在特定的测试中？该测试有什么其他人没有的？
什么是错误？如果是访问冲突，是否有模式发生在哪里？如果地址较低，则可能意味着某处存在未初始化的指针。
程序是否因调试配置而崩溃但未连接调试器？如果是这样，那很可能是 John Smithers 指出的线程同步问题。
您是否尝试过通过 Purify 等分析器运行代码？它很慢，但通常值得等待。
无论如何都要尝试调试发布配置。它只会转储程序集，但它仍然可以指示发生的情况，例如代码指针在垃圾中间跳转或在外部库中遇到断点。
您使用的是英特尔架构吗？如果没有，请注意内存对齐错误，它们在某些架构上会在没有警告的情况下硬崩溃，并且那些编解码器算法往往会产生很多这种情况，因为它们被过度优化了。
【讨论】：
您确定没有预编译指令，例如，在发布模式下忽略一些非常重要的代码，但在调试模式下允许它们？
另外，您是否实施了任何可能指出引发错误的确切程序集的日志记录？
【讨论】：
我会更详细地查看崩溃 - 如果它在测试用例中崩溃，那么听起来很容易重现，这通常是最大的挑战。
【讨论】：
要考虑的另一件事：在调试模式下，变量初始化为 0xCCCCCCCC 而不是零。这可能会产生一些令人讨厌的副作用。
【讨论】：