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

Question

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.

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

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

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

Answer 1

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 bt will list the stack trace for the main thread, and thread apply all bt will list the stack trace for all threads.

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.

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.

Edit:

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

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.

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.

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 -i it will pop up a dialog to let you set the options.

Answer 2

There's a file named gdbinit in 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 gdbinit in 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).

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.