【发布时间】：2011-12-06 08:50:12
【问题描述】：
当应用程序导致难以发现或跟踪的严重段故障问题时。我可以使用调试版本并在问题发生时生成核心转储文件。并使用核心转储文件调试此应用程序。
但是如何在发布时追踪应用程序中的异常错误？发布版本中似乎没有核心转储文件。虽然 log 是一个选项，但当出现难以追踪的 bug 时，它是无用的。
所以我的问题是如何在发布版本中追踪那些难以追踪的错误？有什么可用的建议或技术吗？
以下参考可能有助于讨论。
【问题讨论】：
【发布时间】：2011-12-06 08:50:12
【问题描述】：
您可以使用gcc -g -O2 编译发布版本...
缺少核心转储与您的用户resource limits 设置有关（除非应用程序显式调用setrlimit 或setuid；那么您应该提供一种方法来避免该调用） .您可以教您的用户如何获取核心转储（使用适当的bash ulimit builtin）。
（并且有一些晦涩的方法可以将调试信息放在可执行文件之外）
【讨论】：
发行版提供-dbg packages，为程序提供调试符号。它们与二进制包一起构建，可以为您的用户提供从核心转储生成有意义的回溯的能力。如果您使用相同的实用程序构建您的软件包，您可以为您自己的软件“几乎免费”获得这些 -dbg 软件包。
【讨论】：
我建议使用崩溃报告系统，根据我的经验，我们的 windows 客户端程序使用 google 的 break-pad 项目，当然你可以自己编写。
Google break-pad 是一个开源的多平台崩溃报告系统，它可以在发生异常或崩溃时进行 mini 或 full 内存转储，然后您可以将其配置为将转储文件和任何附加文件上传到特定的ftp server 或者 http server，非常有利于查找bug。
这是链接：
【讨论】：
-
我在我的进程中使用 break-pad 作为线程，而不是守护进程。 Break-pad 只是启动线程并等待信号或异常，我认为在运行时不会影响性能。
询问“客户”他或她做了什么导致崩溃的描述，并尝试使用您自己的具有调试信息的版本复制它。
困难的部分是从客户那里获得正确的信息。他们经常会说他们没有做任何特别的事情或与以前没有什么不同。如果可能的话，去看看有问题的人，并要求他们做他们所做的使程序崩溃的事情，并写下每一个步骤。
【讨论】：
-
嗯，你知道写下这些步骤真的很难。甚至我们也有这些步骤。它无法重现客户描述的错误。所以我在这里询问一种可能的方法来告诉客户打开标志并运行应用程序。当它崩溃时。向我发送 XXX 个文件。
-
好的，有时，我们会向客户发送调试版本，调试版本永远不会崩溃。但是我已经检查了那些 DEBUG MACRO，并且不知道根本原因。所以我只想使用相同的二进制文件并生成一些核心转储文件并使用核心转储文件调试问题。无论如何，我只想使用相同的二进制文件来了解那里发生的事情。