如果调试运行良好，但发布崩溃该怎么办

Question

我有一个在调试版本中运行得很好的应用程序，但是当我在发布版本中启动它时，我得到了一个

unhandled Exception at 0x0043b134 in myapp.exe: 0xC0000005:
Access violation while reading at position 0x004bd96c

如果我点击'break'，它会告诉我没有加载符号，并且无法显示源代码。

在这种情况下我能做些什么来追查问题？

Answer 1

这种问题通常是由于单元化变量造成的。我会从那里寻找你的问题。

调试模式更宽容，因为它经常被配置为初始化尚未显式初始化的变量。

也许您正在删除一个单位指针。在调试模式下，它可以工作，因为指针被清零，删除ptr在NULL时可以正常。在释放它是一些垃圾，然后删除ptr实际上会导致问题。

Answer 2

可能有两件事：

• 除了支票本身之外，你的一个或多个断言都做了必要的工作
• 其他东西

要排除前者，请尝试在调试版本中将assert重新定义为空操作。如果没有一些断言导致崩溃，你会看到它。否则，它就是其他东西。

另外，我假设你有版本控制。这刚开始发生了吗？您可以分析上周的代码更改。

最后，即使在调试模式下没有崩溃，运行内存检查工具也可能有助于发现不正确的内存访问。

Answer 3

两个步骤：

  

a）使用debug构建发布版本   符号（至少可以与VS一起使用）

     

b）中   不使用构建版本构建   优化

如果问题仍然存在，那么它很容易修复。它是almsot，好像问题出在调试版本中。

如果在启用优化设置时出现问题，那么这非常困难，必须以具体情况进行处理。

Answer 4

从main函数的开头直接跟踪插入日志输出的问题。

Answer 5

如果它不是内存问题，那么您必须在发行版中启用断言。对于内存问题，我希望你有好的单元测试。你很容易用valgrind来解决这些问题。

btw为什么人们在发布版本中禁用断言？在99％的情况下，它们不会导致性能问题，并且可以很好地检测错误。

Answer 6

我有这个问题，发布/调试在visual studio中运行良好，调试工作独立，但发布崩溃独立。调试对我来说不是特别准确，我的解决方案是：

注释掉大部分代码，然后构建，测试，取消注释，重复，直到找到导致崩溃的部分。

在我的情况下，它传递的指针指向一个太小而不能用于函数的数组。

Answer 7

您确定两个版本都使用相同的.dll吗？我花了一个小时想知道为什么我的程序在调试模式下编译但没有在发布模式下编译，我只是忘了更新发布文件夹中的dll。

Answer 8

在Windows上使用Microsoft debugdiag进行故障转储（它是免费的）并使用相同的方法分析转储。它为崩溃的函数提供了一个很好的调用堆栈。虽然，如果它一直在崩溃，它可能是堆损坏的问题。然后，您需要结合debugdiag使用全局标志（或gflags，它是免费的调试套件的微软工具的一部分）。 Gflags会为您提供堆实际上已损坏的位置。希望有所帮助。

Answer 9

不看代码，很难说出什么是坏的。以上所有建议都很好并且很有帮助，但我发现最有帮助修复这类事情的是以块的形式运行程序的某些部分。即，注释掉许多代码/功能，然后运行该程序，看它是否崩溃。如果没有，则取消注释某些功能，然后重新运行，依此类推。这样，您就可以将问题缩小到导致此问题的确切代码。

在大多数情况下，这是由于一些缓冲区溢出而发生的，Debug构建可以防范这些溢出。

Answer 10

对我来说，问题是构造函数正在以错误的顺序初始化2个成员变量。即与他们宣布的订单不同。
我很惊讶初始化顺序实际上有所不同。