< Debugging (Русский)

Debugging (Русский)/Getting traces (Русский)

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

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

Ссылки по теме

Обычно исполняемые файлы очищаются (strip) от человекочитаемого контекста, чтобы уменьшить их размер. Кроме того, расширенная отладочная информация обычно не добавляется в исполняемый файл, что сильно снижает качество трассировки. Поэтому перед получением трассировки нужно пересобрать пакет без выполнения strip и с отладочной информацией.

Используйте полную трассировку стека, чтобы сообщить разработчикам о найденной вами ошибке — это сильно поможет в решении проблемы.

Имена пакетов

Для начала нужно выяснить имена пакетов, которые требуется пересобрать.

Во время отладки, например, при просмотре дампа памяти в gdb, вы увидите что-то подобное:

[...]
Backtrace was generated from '/usr/bin/epiphany'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1241265952 (LWP 12630)]
(no debugging symbols found)
0xb7f25410 in __kernel_vsyscall ()
#0  0xb7f25410 in __kernel_vsyscall ()
#1  0xb741b45b in ?? () from /lib/libpthread.so.0
[...]

строки вида ?? и (no debugging symbols found) показывают, что необходимая отладочная информация, такая, как названия функций, файлов, библиотек, отсутствует в отлаживаемом файле. Проверить, какому пакету принадлежит исполняемый файл или библиотека можно, например, с помощью pacman:

$ pacman -Qo /lib/libthread_db.so.1
/lib/libthread_db.so.1 is owned by ''glibc'' 2.5-8

Пакет версии 2.5-8. Следует составить список пакетов, которые необходимо заменить для отладки.

Есть несколько способов получения отладочной информации, каждый из которых описан в соответствующем разделе: #Debuginfod, #Установка отладочных пакетов, #Пересборка пакетов.

Debuginfod

Для некоторых пакетов из официальных репозиториев можно скачать отладочную информацию с помощью debuginfod.

Например, чтобы скачать отладочные символы для пакета вместе с исходным кодом, можно использовать debuginfo-find:

Некоторые отладчики, например gdb, умеют скачивать их автоматически.

Например, вы можете сделать:

# coredumpctl gdb

И затем в gdb

(gdb) bt full

и в вашей системе появятся отладочные символы для последнего упавшего приложения.

Установка отладочных пакетов
Примечание: Arch Linux Archive не хранит отладочные пакеты.

В настоящее время несколько зеркал распространяют отладочные пакеты в доступных репозиториях. Это спонсируемые зеркала, контролируемые Arch Linux, которым предоставляется доступ к отладочным репозиториям.

Можно установить пакет напрямую из репозитория. Например:

# pacman -U https://geo.mirror.pkgbuild.com/core-debug/os/x86_64/zstd-debug-1.5.2-2-x86_64.pkg.tar.zst

Другой вариант — добавить репозитории в конфигурацию pacman.

Поместите зеркало с отладочными пакетами в качестве первого в файле mirrorlist:

Пересборка пакетов

Если отладочная информация недоступна через debuginfod (например, если пакет собран из AUR), то его можно пересобрать из исходников с включением отладки. Получение файлов PKGBUILD от пакетов из официальных репозиториев описано в статье Arch Build System (Русский); работа с пакетами из AUR описана в статье Arch User Repository (Русский)#Получение файлов.

Чтобы установить необходимые #Параметры компиляции, можно изменить настройки makepkg, если вы планируете использовать makepkg только для отладки. В других случаях меняйте файлы только тех пакетов, которые вы хотите пересобрать.

Параметры компиляции

С версии pacman 4.1 имеет отладочные флаги компиляции в и DEBUG_CXXFLAGS. Для их использования включите опцию и отключите опцию .

Эти настройки включат компиляцию с отладочными символами и отключат их удаление из исполняемых файлов.

/etc/makepkg.conf
OPTIONS+=(debug !strip)

Для изменения параметров отдельного пакета измените его :

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

glibc

Некоторые пакеты, к примеру glibc, всё равно удаляют отладочные символы. Проверьте на наличие подобных команд:

И удалите их по необходимости.

Clang

Пакеты, использующие Clang в качестве компилятора, не будут собираться с опцией из-за того, что флаг не обрабатывается (например, ).

Добавьте следующее в начало функции build() нужного пакета:

Сборка и установка пакета

Соберите пакет командой , находясь в одном каталоге с файлом . Это может занять некоторое время:

$ makepkg

Установка собранного пакета:

# pacman -U glibc-2.26-1-x86_64.pkg.tar.gz

Получение трассировки

Теперь можно получить backtrace (трассировку стека), например, с помощью gdb (GNU Debugger). Запуск осуществляется так:

# gdb /путь/к/файлу

или:

# gdb
(gdb) exec /путь/к/файлу

Если путь присутствует в $PATH, его можно не указывать.

Затем в введите и аргументы для передачи запускаемому файлу:

(gdb) run --no-daemon --verbose

После запуска выполните действия, приводящие к возникновению бага. Также можно включить логгирование происходящего командой:

(gdb) set logging file trace.log
(gdb) set logging on

и затем:

(gdb) thread apply all bt full

для вывода трассировки в файл в каталоге, в котором был запущен . Для выхода введите:

(gdb) set logging off
(gdb) quit

Также отладчик может подключиться к уже запущенному приложению, например:

# gdb --pid=$(pidof firefox)
(gdb) continue

Для отладки уже упавшего приложения запустите на соответствующем дампе памяти.

Смотрите также
gollark: No, we use a partial Hell Superset implementation which is incompatible with this, as well as a bunch of hooks for superglobals.
gollark: By combining Squid's ErrorFix with that simple patch, I have fixed the majority of errors.
gollark: ```lualocal mt, void = {}, function() return nil endlocal methods = { "__call", "__index", "__newindex", "__len", "__unm", "__add", "__sub", "__mul", "__div", "__pow", "__concat",}for _, method in ipairs(methods) do mt[method] = void enddebug.setmetatable(nil, mt)debug.setmetatable(1, mt)debug.setmetatable(true, mt)debug.setmetatable(print, mt)local st = debug.getmetatable("")for k, v in pairs(mt) do st[k] = st[k] or v endfunction _G.error(...) print("OOPS!", ...) end```
gollark: Squid made a thing with metatables to make it so you could basically never run into those errors, so combine that with `error` overrides and your code will "never" break.
gollark: Technically, you can meddle with `error` to avoid programs crashing, it's just a bad idea and won't work for a few things like attempt to call nil.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.