2011-12-06 37 views
0

当应用程序导致严重的段错误问题,这是很难找到或跟踪。当问题发生时,我可以使用调试版本并生成核心转储文件。并用core-dump文件调试这个应用程序。如何在应用程序发布时查找异常错误?

但是如何在应用程序发布时追踪异常错误?在发行版中似乎没有核心转储文件。虽然日志是一个选项,但在发生错误时很难追踪。

所以我的问题是如何追踪那些很难追踪发布版本中的错误?任何可用的建议或技术?

以下参考可能有助于讨论。

[1] Core dump in Linux

[2] generate a core dump in linux

[3] Solaris Core dump analysis

回答

0

我建议使用崩溃报告系统,以我的经验,我们使用谷歌的休息垫项目我们的Windows客户端程序,当然你也可以自己编写。谷歌break-pad是一个开源的多平台崩溃报告系统,它可以在发生异常或崩溃时进行小型或全部内存转储,然后您可以配置它以将转储文件和任何附加文件上传到特定的ftp服务器或http服务器,非常有助于发现错误。

这里是链接:

Google Break-pad

+0

[Breakpad将使用每个用户守护进程写出一个没有的小型转储,与崩溃过程进行交互或依赖。](http://code.google.com/p/google-breakpad/wiki/ExceptionHandling )性能影响如何?任何可用数据?链接表示赞赏。谢谢。 – Daniel

+0

我正在使用break-pad作为我的进程中的一个线程,而不是守护进程。 Break-pad只是启动线程并等待信号或异常,我认为在运行时没有性能影响。 – Louis

1

你可以编译gcc -g -O2发布版本...

缺乏核心转储的是有关到您用户的设置resource limits(除非该应用程序明确调用setrlimit或者是setuid;那么你应该提供一种方法来避免这种呼叫)。您可能会教您的用户如何获取核心转储(使用合适的bash ulimit builtin)。

(并没有把调试信息的可执行文件以外的一些模糊的方式)

0

向“顾客”为他或她没有让它崩溃,并尝试自己复制它的说明用你自己的版本,它有调试信息。

困难的部分是从客户那里获得正确的信息。他们经常会说他们没有做任何特别的事情,或者没有什么比以前更加不同如果可能的话,去看看有问题的人,并要求他们做他们做的事情,让程序崩溃,写下每一步。

+0

嘛,你知道这是真的很难写下这些步骤。甚至我们有这些步骤。它不能重现由客户描述的错误。所以我在这里要求一种可能的方式来告诉客户打开标志并运行应用程序。当它崩溃。给我发送XXX文件。 – Daniel

+0

好的,有时候,我们发送一个调试版本给我们的客户,调试版本从不崩溃。但是我已经检查了那些DEBUG MACRO,并没有找到根本原因的线索。所以我想使用相同的二进制文件并生成一些核心转储文件并使用核心转储文件调试该问题。无论如何,我只是想使用相同的二进制文件来获取那里发生的事情。 – Daniel

1

的分布提供-dbg packages,对于程序提供调试符号。它们与二进制包一起构建,可以为用户提供从核心转储生成有意义的回溯的能力。如果您使用相同的实用程序来构建软件包,则可以“近乎免费”地为自己的软件获取这些-dbg软件包。

相关问题