我使用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中有介绍-请参阅如何分析程序'；s核心转储文件与gdb？
-
您可能需要将Python解释器堆栈与您正在运行的Python代码关联起来。为此，您需要为gdb安装Python调试符号和Python扩展。PythonWiki在这里为如何做到这一点提供了很好的建议。
核心转储最常见的原因是访问您无法访问的内存地址(不属于程序的内存)。操作系统根据程序试图访问无效内存地址的方式，使用名为SegFault或BusError的中断来中断程序。然后内核将强制关闭该程序。如果内核已配置为创建核心转储(内存和程序堆栈的转储)，则其中一个将保存到磁盘。正如在另一个答案中所指出的，您可以将核心转储加载到GDB或其他调试器中，并显示程序崩溃时正在执行的操作。这可能会也可能不会给你带来眼前的问题。通常情况下，即使是有经验的程序员也很难使用这些工具，所以要注意。如果你想尝试使用GDB，试试这个：
$gdb/path/to/cracking/program/binary/path/to/core
(gdb)bt
"bt"将显示"backtraces"(也称为StackTraces)，这对程序员追踪错误非常有用。
如果你能够重现错误，那么你可能很幸运地向有问题的程序的创建者提交了一份详细的错误报告。即使我是一名资深软件开发人员，也会时不时地走这条路