Debugging (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
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
Эта статья или раздел нуждается в
переводе
Примечания:
... (обсуждение:
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).
Смотрите также
Gentoo:Project:Quality Assurance/Backtraces