我的应用程序最近在客户端的计算机上崩溃了。我怀疑这是因为PyQt自己的内存管理,如果处理不当会导致无效的内存访问。
当Python崩溃时,不会打印回溯,只会将数据转储写入磁盘。
是否有可能找到崩溃发生在Python代码中的哪个位置?
答案 0 :(得分:7)
这是一个linux核心转储吗?如果是这样,你可以用gdb检查它。您需要在具有相同操作系统和Python版本的系统上运行,包括第三方库。运行gdb -c /path/to/core/file
。加载gdb后,命令bt
将列出主线程的堆栈跟踪,thread apply all bt
将列出所有线程的堆栈跟踪。
这有多大取决于Python的版本是否包含完整的符号表(即Python的调试版本) - 如果不是,那么您只会看到地址作为主要C入口点的偏移量。然而,这仍然可以用于诊断出错的地方。
如果是其他操作系统不支持gdb,那么你就是自己 - 可能是操作系统会有自己的调试工具。
修改强>
Python维基上有一个描述how to get a python stack trace with gdb的页面。
然而,快速查看问题中的链接表明操作系统是Windows,因此gdb没用。 Windows转储中的信息很少,所以我认为你运气不好。
我唯一的建议是:
尝试在内部重现崩溃。
让用户在运行可以捕获崩溃的工具并执行适当的内存转储时重现该错误。自从我做了严格的Windows调试以来已经有十年了,所以我不知道现在有哪些工具可用 - 曾经有一个名为Dr.Watson,但它可能已经过时了。
如果用户无法重现崩溃,那么你运气不好,另一方面如果它再也不会发生,那就不是那么大的问题了。 ; - )
<强>更新强>
Google告诉我,Watson博士仍然是Windows XP上的默认崩溃处理程序(可能是其他版本的Windows) - 问题中链接的堆栈转储可能来自它。但是,Dr Watson保存的默认数据相当少,但您可以将其配置为保存更多 - 请参阅this article。简而言之,如果您运行drwtsn32 -i
,它将弹出一个对话框,让您设置选项。
答案 1 :(得分:2)
Python源代码树(gdbinit
)中有一个名为Misc/gdbinit
的文件,它为gdb提供了一组宏,以便显示当前的解释器上下文。只需在gdb中键入source gdbinit
,然后就可以执行pystack
等宏。只需读取文件的源代码即可获得可用宏列表。
(你可以直接在这里找到它:http://svn.python.org/view/python/trunk/Misc/gdbinit?view=log)。
当然,如果崩溃严重到破坏了解释器的内部结构,那么宏可能会失败或崩溃。此外,最好在调试模式下编译解释器,否则gdb可能无法找到所需的符号和变量。
答案 2 :(得分:1)
不确定它是否有帮助,但是如果你能捕获异常,你可以使用http://github.com/gooli/pydump来存储转储并稍后在Python调试器中加载它。
答案 3 :(得分:0)
您的应用程序是否生成日志?如果是这样,您可以让日志记录生成内存日志,您可以在核心转储中找到该日志。此外,您可以让他们自己发送日志文件而不是核心转储。