我可以使用数据转储找出 Python 应用程序崩溃的位置吗？

Can I find out where a Python application crashed using the data dump?

提问by Georg Sch?lly

My application crashed recently on a client's computer. I suspect it's because of PyQt's own memory management, which can lead to a invalid memory accesses when not properly handled.

我的应用程序最近在客户端的计算机上崩溃了。我怀疑这是因为 PyQt 自己的内存管理，如果处理不当会导致无效的内存访问。

When Python crashes like this, no backtrace is printed, only a data dump is written to the disk.

当 Python 像这样崩溃时，不会打印任何回溯，只会将数据转储写入磁盘。

Is there a possibility to find out where in the Python code the crash occured?

是否有可能找出崩溃发生在 Python 代码中的哪个位置？

Here's the dump: http://pastie.org/768550

这是转储：http: //pastie.org/768550

回答by Dave Kirby

Is this a linux core dump? If so you can examine it with gdb. You will need to run in on a system with an identical OS and version of Python, including 3rd party libraries. Run gdb -c /path/to/core/file. Once gdb has loaded then the command btwill list the stack trace for the main thread, and thread apply all btwill list the stack trace for all threads.

这是 linux 核心转储吗？如果是这样，您可以使用 gdb 检查它。您需要在具有相同操作系统和 Python 版本（包括 3rd 方库）的系统上运行。运行gdb -c /path/to/core/file。一旦 gdb 加载完毕，该命令bt将列出主线程thread apply all bt的堆栈跟踪，并将列出所有线程的堆栈跟踪。

How useful this will be depends on whether the version of Python includes the full symbol table (i.e. is a debug build of Python) - if it is not, then you will only see addresses as offsets to the main C entry points. However this can still be of some use in diagnosing what went wrong.

这有多有用取决于 Python 的版本是否包含完整的符号表（即是 Python 的调试版本）——如果不是，那么您将只会看到地址作为主要 C 入口点的偏移量。然而，这在诊断出了什么问题时仍然有一定的用处。

If it is some other OS that does not support gdb then you are on your own - presumably the OS will have its own debugging tools.

如果是其他一些不支持 gdb 的操作系统，那么你就靠自己了——大概操作系统会有自己的调试工具。

Edit:

编辑：

There is a page on the Python wiki describing how to get a python stack trace with gdb.

Python wiki 上有一个页面描述了如何使用 gdb 获取 python 堆栈跟踪。

However a quick look at the link in the question shows that the OS is Windows, so gdb is of no use. The information in the Windows dump is minimal, so I think you are out of luck.

但是，快速查看问题中的链接会显示操作系统是 Windows，因此 gdb 没有用。Windows 转储中的信息很少，所以我认为您不走运。

My only suggestions are:

我唯一的建议是：

1. try to reproduce the crash in-house.

2. get the user to reproduce the bug while running a tool that will catch the crash and do a proper memory dump. It is about a decade since I have done serious windows debugging so I don't know what tools are available now - there used to be one called Dr.Watson, but it may be obsolete.

1. 尝试在内部重现崩溃。

2. 让用户在运行能够捕获崩溃并进行适当内存转储的工具时重现该错误。自从我进行认真的 Windows 调试以来大约有十年了，所以我不知道现在有哪些工具可用 - 曾经有一个叫做 Dr.Watson 的工具，但它可能已经过时了。

If the user can't reproduce the crash then you are out of luck, on the other hand if it never happens again it is not really that big a problem. ;-)

如果用户不能重现崩溃，那么你就不走运了，另一方面，如果它再也不会发生，那也不是什么大问题。;-)

Update:

更新：

Google tells me that Dr Watson is still the default crash handler on Windows XP (and presumably other versions of Windows) - the stack dump that was linked in the question probably came from it. However the default data saved by Dr Watson is fairly minimal, but you can configure it to save more - see this article. In short, if you run drwtsn32 -iit will pop up a dialog to let you set the options.

Google 告诉我，Dr Watson 仍然是 Windows XP（可能还有其他版本的 Windows）上的默认崩溃处理程序——问题中链接的堆栈转储可能来自它。然而，Dr Watson 保存的默认数据相当少，但您可以对其进行配置以保存更多 - 请参阅本文。总之，如果你运行drwtsn32 -i它会弹出一个对话框让你设置选项。

回答by Antoine P.

There's a file named gdbinitin the Python source tree (in Misc/gdbinit) which provides a set of macros for gdb so as to display the current interpreter context. Just type source gdbinitin gdb and then you can execute macros such as pystack. The list of available macros can be obtained simply by reading the file's source code. (you can find it directly here: http://svn.python.org/view/python/trunk/Misc/gdbinit?view=log).

gdbinit在 Python 源代码树 (in Misc/gdbinit) 中有一个文件，它为 gdb 提供了一组宏，以便显示当前的解释器上下文。只需输入source gdbinitgdb，然后您就可以执行诸如pystack. 可以通过阅读文件的源代码简单地获得可用宏的列表。（你可以直接在这里找到它：http: //svn.python.org/view/python/trunk/Misc/gdbinit?view=log）。

Of course, if the crash is so severe that it has corrupted the interpreter's internal structures, the macros may fail or crash. Also, it is better to compile the interpreter in debug mode, otherwise gdb may fail to locate the required symbols and variables.

当然，如果崩溃严重到破坏了解释器的内部结构，宏可能会失败或崩溃。此外，最好在调试模式下编译解释器，否则 gdb 可能无法定位所需的符号和变量。

回答by elifiner

Not sure if it helps, but if you can catch the exception, you could use http://github.com/gooli/pydumpto store a dump and load it later in a Python debugger.

不确定它是否有帮助，但如果您可以捕获异常，则可以使用http://github.com/gooli/pydump存储转储并稍后在 Python 调试器中加载它。

回答by S.Lott

Does your application produce a log? If so, you can have logging produce an in-memory log which you might be able to find within the core dump. Also, you can have them send you the log file itself insteadof the core dump.

您的应用程序是否生成日志？如果是这样，您可以让日志记录生成一个内存日志，您可以在核心转储中找到该日志。此外，您可以让他们向您发送日志文件本身而不是核心转储。