如何使用GDB分析崩溃转储文件

概述如何使用GDB分析崩溃转储文件

我有一个在Cent OS下运行的服务器应用程序。 服务器每秒响应很多请求，但在每个小时左右之后会重复崩溃，并创build崩溃转储文件。 情况真的很糟糕，我需要尽快找出事故原因。

我怀疑这个问题是一个并发问题，但我不确定。 我有权访问源代码和崩溃转储文件，但我不知道如何使用崩溃转储来指出问题。

任何build议，非常感谢。

ntdll模块不正确加载windbg，但为什么？

WinDbg会话variables – 别名与用户定义的伪寄存器

在linux上重复Visual Studio的内存违规检测

是否有可能直接识别覆盖整个堆栈的错误代码？

deBUGging线程时无限循环

用于STL容器的C ++ IDE

使用linux错误注入框架

在Eclipse中deBUGgingJava应用程序（Tanuki服务包装）

在windows中deBUGgingGo（golang）代码

在Win 10中卸载DLL时deBUGging崩溃，但不是Win 7

首先要查找的是当程序崩溃时得到的错误信息。 这会经常告诉你发生了什么样的错误。 例如， “分段错误”或“SIGSEGV”几乎肯定意味着您的程序已经取消了引用NulL或其他无效的指针。 如果程序是用C ++编写的，那么错误信息通常会告诉你任何未捕获异常的名字。

如果您没有看到错误消息，则从命令行运行程序，或者将其输出输出到文件中。

为了使核心文件真正有用，你需要编译你的程序，而不用优化和调试信息。 GCC需要以下选项： -g -O0 。 （确保你的版本没有其他-O选项。）

一旦你有核心文件，然后打开它在gdb中：

gdb YOUR-APP COREfile

键入要查看发生崩溃的点的位置。 你基本上是在一个正常的调试会话 – 你可以检查变量，上下移动堆栈，在线程之间切换。

如果你的程序崩溃了，那么它可能是一个无效的内存访问 – 所以你需要寻找一个零值的指针，或指向看起来不好的数据。 您可能无法在堆栈底部找到问题，您可能需要将堆栈向上移动几个级别，然后才能发现问题。

祝你好运！

如果问题需要一个小时左右才能体现出来，那么这可能是一个内存问题 – 可能会用完，也可能是践踏（例如使用已经释放的内存）。

你说你有崩溃转储文件 – 这是一个核心转储？

假设你有一个核心转储，那么第一步应该是打印栈回溯：

gdb program core > where

这应该告诉你程序是在什么时候发生崩溃的。 还有什么可用取决于如何编译服务器。 如果可能的话，你应该重新编译启用调试（这将与GCC的“ -g ”标志）。 这会给你从堆栈回溯更多的信息。

如果您的问题与内存有关，请考虑使用valgrind运行。

还要考虑使用malloc()的调试版本来构建和运行。 调试版本将检测正常版本错过的内存滥用，或者崩溃。

gdb -c core.file exename bt

假设exename是用调试符号构建的（并且所有的动态依赖都在路径中），这将会得到一个回溯。 'up'和'down'会在堆栈中上下移动， p varname可以用来检查locals和参数。

你也可以尝试在valgrind下运行它：

valgrind --tool=memcheck --leak-check=full exename

您的应用是否创建核心文件？ 如果是这样，我会使用gdb来调试这个问题。

总结

以上是内存溢出为你收集整理的如何使用GDB分析崩溃转储文件全部内容，希望文章能够帮你解决如何使用GDB分析崩溃转储文件所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。