我有一个在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来调试这个问题。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
