Python服务器“Aborted（Core dumped）”
我使用web.py来创建Python Web服务器。 调用此服务器以解决线性编程问题，并使用库CBC来执行此操作。
每隔一段时间，服务器就会崩溃一个看起来像这样的日志：
78.243.184.3:56271 - - [03/Jun/2016 04:35:54] "HTTP/1.1 GET /optimization" - 200 OK Aborted (core dumped) 我相信“Aborted（core dumped）”是一个C错误，所以它来自web.py或CBC。
有没有办法追溯错误的来源？
核心转储是由Web服务器中的本机代码故障引起的。 Python现在相当坚固，所以这些错误几乎总是由我的经验中的C扩展中的错误引起的。
因此，你有3个问题。
-
您需要找到核心转储文件。 这通常位于转储进程的当前工作目录中。 但是，有一些可以改变这种情况的配置选项 。
-
您需要调试失败的调用堆栈。 这在StackOverflow中有所介绍 – 请参阅如何使用gdb分析程序的核心转储文件？
-
您可能需要将Python解释器堆栈与您正在运行的Python代码相关联。 为此，您需要为gdb安装Python调试符号和Python扩展。 Python wiki在这里有关于如何做到这一点的好建议。
核心转储的最常见原因是访问您无法访问的内存地址（不属于您的程序的内存）。 操作系统通过一个名为SegFault或BusError的中断来中断程序，这取决于程序如何尝试访问无效的内存地址。 然后程序将由内核强制关闭。 如果内核已配置为创建核心转储（内存转储和程序堆栈），则会将其保存到光盘。 如另一个答案中所述，您可以将核心转储加载到GDB或其他调试器中，并显示程序在崩溃时正在执行的操作。 这可能会或可能不会给你带来问题。 通常情况下，即使是有经验的程序员也很难使用这些工具，所以要注意。 如果您想尝试使用GDB，请尝试以下方法：
$ gdb / path / to / crashing / program / binary / path / to / core
（gdb）bt
‘bt’将显示’backtraces’，也称为StackTraces，对于程序员追踪错误非常有用。
如果您能够重现错误，那么您可能很幸运地向相关程序的创建者提交了详细的错误报告。 甚至我作为高级软件开发人员也不时采用这种方式。 🙂