Debugging (Русский)

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Debugging. Дата последней синхронизации: 15 февраля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Эта страница в основном посвящена тому, как собрать побольше информации для сообщений об ошибках. Несмотря на то, что используется слово «отладка», она не предназначена в качестве руководства по отладке программ в процессе их разработки.

Когда приложение не работает

Запустите его через командную строку

Если приложение внезапно падает, попробуйте запустить его через терминал. Введите в нём имя приложения (обычно строчными буквами). Если вы не знаете имя исполняемого файла, а знаете только имя пакета, следующая команда может найти имя исполняемого файла:

$ pacman -Ql имяпакета | grep ' /usr/bin/.'

Проверьте наличие дампа памяти

Дамп памяти (core dump) — это файл, в который записывается адресное пространство (память) процесса при его нештатном завершении. Если приложение скомпилировано с поддержкой отладки, этот дамп можно использовать для выяснения того, что и где пошло не так.

Расположение дампов памяти может отличаться в зависимости от настроек операционной системы. Как узнать, включена ли генерация дампов и куда они попадают, описано в статье Дамп памяти.

Ошибки сегментирования

Есть несколько методов, с помощью которых можно выяснить, что пошло не так. Наденьте шляпу детектива.

Gdb

gdb — проверенный временем инструмент отладки приложений. Подробные инструкции по использованию и получению трассировки описаны в статье Отладка/Трассировка#Получение трассировки. После запуска приложения через gdb вам, вероятно, придётся подождать какое-то время, пока не случится ошибка сегментирования. После этого опубликуйте трассировку на pastebin-сервисе и добавьте полученный URL в сообщение об ошибке.

Если у вас есть дамп памяти, его можно использовать вместе с gdb для получения backtrace:

$ gdb имяприложения core
bt full

Valgrind

Если у вас есть бинарный файл с отладочными символами и без inline-функций, то обычно хорошей идеей является запуск программы через valgrind. Это инструмент, который эмулирует процессор и обычно показывает, где что-то идёт не так, или предоставляет дополнительную информацию в дополнение к gdb.

$ valgrind имяприложения

Это позволит получить много полезной отладочной информации в случае сбоя. Попробуйте опции -v и --leak-check=full, чтобы собрать ещё больше информации.

Также можно использовать команду:

$ valgrind --tool=callgrind имяприложения

и запустить вывод через kcachegrind, чтобы графически исследовать функции, используемые программой. Если программа зависает, это облегчает определение места ошибки.

Отсутствующие файлы или библиотеки

Strace

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

Следующая команда покажет файлы, которые приложение пытается открыть:

$ strace -eopen имяприложения

Полученный вывод можно опубликовать на pastebin-сервисе.

Совет: Если вы хотите передать вывод strace в grep, попробуйте: strace -o /dev/stdout имяприложения | grep строка.

LD_DEBUG

Установка LD_DEBUG=files дает ещё один обзор того, какие файлы ищет приложение:

$ LD_DEBUG=files имяприложения > файл.log 2>&1

Вывод будет записан в файл.log.

Подробнее: ld-linux(8).

Readelf

Tango-preferences-desktop-locale.pngЭта статья или раздел нуждается в переводеTango-preferences-desktop-locale.png

Примечания: ... (обсуждение: Talk:Debugging (Русский)#)

If you get no such file or directory when running an application, try the following command:

$ readelf -a /usr/bin/appname | grep interp

(replace /usr/bin/appname with the location of your executable)

Make sure the interpreter in question (like /lib/ld-linux-x86-64.so.2) actually exists. Install ld-lsb if need be.

Если программа написана не на C или C++, а является скриптом

Используйте команду file, чтобы узнать информацию об исполняемом файле:

$ file /usr/bin/имяприложения

Если она выведет ELF, то это бинарный исполняемый файл, который обычно компилируется из кода C или C++. Если она выведет Python script, значит вы имеете дело с приложением, написанным на Python.

Если это шелл-скрипт, откройте его в текстовом редакторе и посмотрите (обычно в конце файла), есть ли в нём имя реальной программы (ELF-файла). Можно временно прописать "gdb" прямо в скрипт перед именем исполняемого файла в целях отладки. Используйте префикс gdb --args, если программе нужно передать аргументы.

Для чистых шелл-скриптов можно использовать bash -x имя_скрипта или bash -xv имя_скрипта, что выведет подробную информацию о процессе выполнения скрипта.

Тексты ошибок в Python-приложениях часто содержат информацию о том, в каком файле и на какой строке произошел сбой. Если вы знаете Python, вы можете попытаться исправить это и вложить своё исправление в сообщение об ошибке.

Отправка собщения об ошибке

Сообщите об ошибке на https://bugs.archlinux.org или, возможно, отправьте сообщение непосредственно разработчикам приложения, а затем укажите ссылку на него в сообщении для Arch Linux. Это поможет всем нам.

Однако если вы считаете, что что-то не так с самим приложением, а не с тем, как оно собрано в Arch Linux, то сообщите об ошибке непосредственно разработчикам приложения (в upstream).

Смотрите также