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