Могу ли я узнать, где произошло сбой приложения Python, используя дамп данных?

Question

Мое приложение недавно зависло на компьютере клиента. Я подозреваю, что это из-за собственного управления памятью PyQt, которое может привести к недопустимому доступу к памяти при неправильной обработке.

Когда происходит сбой Python, обратная трассировка не печатается, на диск записывается только дамп данных.

Есть ли возможность узнать, где в коде Python произошел сбой?

Вот дамп: http://pastie.org/768550

Answer 1

Это дамп ядра Linux? Если это так, вы можете проверить это с помощью GDB. Вам нужно будет работать в системе с идентичной ОС и версией Python, включая сторонние библиотеки. Запустите gdb -c /path/to/core/file. После загрузки GDB команда bt выведет список трассировки стека для основного потока, а thread apply all bt выведет список трассировки стека для всех потоков.

Насколько это будет полезно, зависит от того, включает ли версия Python полную таблицу символов (т. Е. Является ли это отладочной сборкой Python) - если это не так, то вы будете видеть только адреса как смещения основных точек входа C. Однако это все еще может быть полезно при диагностике того, что пошло не так.

Если это какая-то другая ОС, которая не поддерживает gdb, то вы сами по себе - предположительно, ОС будет иметь свои собственные средства отладки.

Edit:

В викитоне Python есть страница, описывающая как получить трассировку стека Python с помощью gdb .

Однако быстрый взгляд на ссылку в вопросе показывает, что ОС - это Windows, поэтому gdb бесполезен. Информация в дампе Windows минимальна, поэтому я думаю, что вам не повезло.

Мои единственные предложения:

1. попытаться воспроизвести аварию на месте.

2. заставьте пользователя воспроизвести ошибку, запустив инструмент, который поймает сбой и сделает правильный дамп памяти. Прошло около десяти лет с тех пор, как я выполнил серьезную отладку Windows, поэтому я не знаю, какие инструменты доступны сейчас - раньше был инструмент под названием Dr.Watson, но он может быть устаревшим.

Если пользователь не может воспроизвести сбой, то вам не повезло, с другой стороны, если это никогда не повторится, это не такая уж большая проблема. ; -)

Обновление:

Google сообщает мне, что д-р Уотсон по-прежнему является обработчиком сбоя по умолчанию в Windows XP (и, вероятно, в других версиях Windows) - дамп стека, который был связан в вопросе, вероятно, произошел от него. Однако данные по умолчанию, сохраняемые доктором Уотсоном, довольно минимальны, но вы можете настроить их, чтобы сохранить больше - см. эту статью Короче говоря, если вы запустите drwtsn32 -i, появится диалоговое окно, в котором вы сможете задать параметры.

Answer 2

В дереве исходного кода Python (в Misc/gdbinit) есть файл с именем gdbinit, который предоставляет набор макросов для gdb для отображения текущего контекста интерпретатора. Просто введите source gdbinit в GDB, и тогда вы сможете выполнять макросы, такие как pystack. Список доступных макросов можно получить, просто прочитав исходный код файла. (Вы можете найти его прямо здесь: http://svn.python.org/view/python/trunk/Misc/gdbinit?view=log).

Конечно, если сбой настолько серьезен, что повредил внутренние структуры интерпретатора, макросы могут выйти из строя или аварийно завершиться. Также лучше скомпилировать интерпретатор в режиме отладки, иначе GDB может не найти нужные символы и переменные.

Answer 3

Не уверен, поможет ли это, но если вы можете перехватить исключение, вы можете использовать http://github.com/gooli/pydump, чтобы сохранить дамп и загрузить его позже в отладчике Python.

Answer 4

Ваше приложение создает журнал? Если это так, вы можете сделать запись в журнале в памяти, которую вы сможете найти в дампе ядра. Кроме того, вы можете сделать так, чтобы они отправляли вам сам файл журнала вместо дампа ядра.