Jump to content

# Debugging (Русский)

2 languages

- English
- 日本語

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

Эта статья или раздел нуждается в переводе

Примечания: ... (обсуждение: 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

Categories:

- Development (Русский)
- System administration (Русский)

Hidden category:

- Pages or sections flagged with Template:Translateme (Русский)