发布版本中的错误在调试模式下不存在的常见原因

只在发布编译模式下出现但在调试模式下不会出现的 bug 和异常程序行为的典型原因是什么？

32445 次浏览
小开

你需要提供更多的信息，但是，是的，这是可能的。这取决于调试版本的作用。您可能会有日志记录或额外的检查，这些记录不会被编译成发布版本。这些仅用于调试的代码路径可能具有意想不到的副作用，这些副作用会以奇怪的方式改变状态或影响变量。调试版本通常运行得更慢，因此这可能会影响线程化和隐藏竞态条件。对于直接从发行版编译器进行优化也是一样，发行版编译器有可能(尽管现在不太可能)使优化短路。

小开

当然，例如，如果您使用

#if DEBUG


//some code


#endif
小开
最佳答案

很多时候，在 C + + 的调试模式下，所有变量都初始化为 null，而在发布模式下，除非明确说明，否则不会发生同样的情况。

检查所有调试宏和未初始化的变量

您的程序是否使用线程，那么优化也可能导致发布模式中的一些问题。

还要检查所有的异常，例如与发布模式没有直接关系的异常，但是有时我们会忽略一些关键的异常，比如 VC + + 中的 mem 访问冲突，但是同样的问题至少在其他操作系统如 Linux、 Solaris 中会出现。理想情况下，您的程序不应该捕获这样的关键异常，如访问 NULL 指针。

小开

如果没有更多的细节，我将假设“ not OK”意味着它要么不编译，要么在运行时抛出某种错误。检查是否有依赖于编译版本的代码，可以通过 #if DEBUG语句，也可以通过标记为 Conditional属性的方法。

小开

太棒了！，如果您有条件编译，可能存在计时错误(优化的发布代码，非优化的调试代码) ，内存重用与调试堆。

小开

进去。NET，即使你不使用像 #if DEBUG这样的条件编译，编译器在发布模式下的优化仍然比在调试模式下更加自由，这也会导致只发布 bug。

小开

其他不同之处可能包括:

  • 在垃圾收集语言中， 收集器通常更具侵略性 在释放模式;
  • 内存的布局可以 往往是不同的;
  • 记忆也许是 以不同方式初始化(如可以是 在调试模式下归零，或重用更多 积极释放) ;
  • 当地人可能会 被提升为在发布中注册值，这可以 引起浮点数问题 价值观。
小开

一个常见的缺陷是在 ASSERT 中使用具有副作用的表达式。

小开

它可以，特别是如果你在 C 领域。

其中一个原因可能是 DEBUG 版本可能会添加代码来检查偏离的指针，并以某种方式保护您的代码免于崩溃(或行为不正确)。如果是这种情况，您应该仔细检查从编译器获得的警告和其他消息。

另一个原因可能是优化(对于发布版本，优化通常是开启的，对于调试，优化是关闭的)。代码和数据布局可能已经进行了优化，而当您的调试程序只是，例如，访问未使用的内存时，发布版本现在正试图访问保留内存，甚至指向代码！

编辑: 我看到其他人提到它: 当然，如果不在 DEBUG 模式下编译，您可能会有整个代码段被有条件地排除在外。如果是这样的话，我希望这是真正的调试代码，而不是对程序本身的正确性至关重要的东西！

小开

有可能。如果发生这种情况，并且不涉及条件编译，那么您可以非常确定您的程序是错误的，并且仅仅由于偶然的内存初始化或内存中的布局而在调试模式下工作！

小开

可以破解有效代码有编译器优化，因为它们太主动了。

尝试在打开较少优化的情况下编译代码。

小开

这是可能的，如果您有条件编译，以便调试代码和发布代码是不同的，并且代码中有一个只在发布模式中使用的 bug。

除此之外，不可能。调试代码和发布代码的编译方式存在差异，在调试器下运行与否的代码执行方式也存在差异，但如果这些差异导致除性能差异以外的任何其他原因，问题就一直存在。

在调试版本中，错误可能不会发生(因为计时或内存分配是不同的) ，但这并不意味着错误不存在。也许还有其他与调试模式无关的因素会改变代码的计时，从而导致错误发生或不发生，但归根结底，如果代码是正确的，那么在任何情况下都不会发生错误。

所以，不，调试版本是不正确的，因为您可以运行它而不会得到一个错误。如果在发布模式下运行时发生错误，那不是因为发布模式，而是因为错误从一开始就存在。

小开

CRT 库函数在调试和发布(/MD vs/MDd)中的行为是不同的。

例如，调试版本通常预先填充传递到指定长度的缓冲区，以验证声明。例如 strcpy_s、 StringCchCopy等。即使字符串提前终止，您的 SzDest最好是 N字节长！

小开

我曾经被一些 bug 所困扰，这些 bug 在 Debug 构建中很好，但在发布构建中崩溃了。有许多潜在的原因(当然包括那些已经在这个帖子中总结出来的原因) ，我被以下所有的原因所困扰:

  • #ifdef _DEBUG中的成员变量或成员函数，以便类在调试生成中具有不同的大小。有时在发布版本中使用 #ifndef NDEBUG
  • 类似地，有一个不同的 #ifdef恰好只存在于两个构建中的一个中
  • 调试版本使用系统库的调试版本，特别是堆和内存分配函数
  • 发布版本中的内联函数
  • 头文件的包含顺序。这应该不会引起问题，但是如果你有像 #pragma pack这样的东西没有被重置，那么这可能会导致讨厌的问题。使用预编译头和强制包含也可能发生类似的问题
  • 缓存: 您可能拥有仅在版本构建中使用的缓存或不同的缓存大小限制之类的代码
  • 项目配置: 调试和发布配置可能有不同的生成设置(在使用 IDE 时可能会发生这种情况)
  • 仅由于调试代码而产生的竞争条件、时间问题和各种副作用

这些年来，我积累了一些深入探究调试/发布 bug 的技巧:

  • 如果可以的话，尝试在调试构建中重现异常行为，更好的方法是编写一个单元测试来捕获它
  • 想想这两者之间的区别: 编译器设置、缓存、仅调试代码。尽量暂时减少这些差异
  • 创建一个关闭优化的版本构建(这样您更有可能在调试器中获得有用的数据) ，或者一个优化的调试构建。通过最小化调试和发布之间的更改，您更有可能分离出导致 bug 的差异。
小开

在非 void 函数中，所有执行路径都应以 return 语句结束。

在调试模式下，如果您忘记以 return 语句结束这样的路径，那么函数通常默认返回0。

但是，在发布模式下，函数可能会返回垃圾值，这可能会影响程序的运行方式。

小开

我只是在调用程序集函数时遇到了这种情况，该函数没有还原寄存器以前的值。

在“发布”配置中，VS 使用/O2进行编译，从而优化了代码的速度。因此，一些局部变量仅仅映射到与上述函数共享的 CPU 寄存器(用于优化) ，就会导致严重的内存损坏。

不管怎样，看看在代码中的任何地方是否间接地扰乱了 CPU 寄存器。

小开

我记得以前我们在 c/c + + 中构建 dll 和 pdb 的时候。

我记得这个:

  • 添加日志数据有时会使 bug 移动或消失，或出现完全其他的错误(所以这不是一个真正的选项)。
  • 这些错误中有许多与 strcpy 和 strcat 中的字符分配以及 char []的数组有关。
  • 我们通过运行边界检查器和简单地修复 内存分配/释放问题。
  • 很多时候，我们系统地遍历代码并固定一个字符分配。
  • 我的两点是，它与内存分配和管理以及调试模式和发布模式之间的约束和差异有关。

然后继续这个循环。

我们有时会暂时将发布版本替换为 dll 的调试版本，以便在处理这些 bug 时不会延迟生产。

小开

另一个原因可能是 DB 调用。 是否在同一线程中多次保存和更新同一记录, 有时是为了更新。 更新可能失败或者不能按预期工作，因为前面的 create 命令仍在处理中，对于更新，db 调用未能找到任何记录。 这在调试中不会发生，因为调试器确保在着陆前完成所有挂起的任务。


提交答案