Как создать полную трассировку стека для mysqld

Частичные трассировки стека в журнале ошибок

Когда mysqld / mariadbd аварийно завершается, по умолчанию он записывает трассировку стека в журнал ошибок. Это происходит потому, что параметр stack_trace по умолчанию имеет значение ON. В обычной релизной сборке трассировка стека в журнале ошибок может выглядеть так:

2019-03-28 23:31:08 0x7ff4dc62d700  InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.2.23/storage/innobase/rem/rem0rec.cc line 574
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
190328 23:31:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
Server version: 10.2.23-MariaDB-10.2.23+maria~stretch
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=234
max_threads=752
thread_count=273
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1783435 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7ff4d8001f28
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7ff4dc62ccc8 thread_stack 0x49000
*** buffer overflow detected ***: /usr/sbin/mysqld terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7ffa09af5bfb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffa09b7e437]
/lib/x86_64-linux-gnu/libc.so.6(+0xf7570)[0x7ffa09b7c570]
/lib/x86_64-linux-gnu/libc.so.6(+0xf93aa)[0x7ffa09b7e3aa]
/usr/sbin/mysqld(my_addr_resolve+0xe2)[0x55ca42284922]
/usr/sbin/mysqld(my_print_stacktrace+0x1bb)[0x55ca4226b1eb]
/usr/sbin/mysqld(handle_fatal_signal+0x41d)[0x55ca41d0a01d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7ffa0b4180e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7ffa09ab7fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7ffa09ab942a]
/usr/sbin/mysqld(+0x40f971)[0x55ca41ab8971]
/usr/sbin/mysqld(+0x887df6)[0x55ca41f30df6]
/usr/sbin/mysqld(+0x863673)[0x55ca41f0c673]
/usr/sbin/mysqld(+0x96648e)[0x55ca4200f48e]
/usr/sbin/mysqld(+0x89b559)[0x55ca41f44559]
/usr/sbin/mysqld(+0x8a15e4)[0x55ca41f4a5e4]
/usr/sbin/mysqld(+0x8a2187)[0x55ca41f4b187]
/usr/sbin/mysqld(+0x8b1a20)[0x55ca41f5aa20]
/usr/sbin/mysqld(+0x7f5c04)[0x55ca41e9ec04]
/usr/sbin/mysqld(_ZN7handler12ha_write_rowEPh+0x107)[0x55ca41d140d7]
/usr/sbin/mysqld(_Z12write_recordP3THDP5TABLEP12st_copy_info+0x72)[0x55ca41b4b992]
/usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0x1206)[0x55ca41b560f6]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x3f68)[0x55ca41b6bee8]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x28a)[0x55ca41b70e4a]
/usr/sbin/mysqld(+0x4c864f)[0x55ca41b7164f]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1a7c)[0x55ca41b737fc]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x176)[0x55ca41b748a6]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x25a)[0x55ca41c3ec0a]
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x55ca41c3ed7d]
/usr/sbin/mysqld(+0xb75791)[0x55ca4221e791]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7ffa0b40e4a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7ffa09b6dd0f]

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

Полная трассировка стека может быть создана только в том случае, если у вас есть символы отладки для вашего mariadbd двоичного файла.

Получение символов отладки для вашего mariadbd исполняемого файла

Данные отладки используются инструментами отладки для создания осмысленной трассировки стека. Важно отметить, что эти пакеты не заменяют какие-либо исполняемые файлы или существующие производственные исполняемые файлы и никоим образом не влияют на работу производственного сервера до установки этих пакетов.

Если вы получаете обратный след для дампа ядра, вы можете перенести дамп ядра на другой сервер, на котором установлены идентичные пакеты mariadb-server и debug info, и выполнить обратный след там без потери информации.

Установка пакетов с данными отладки в Linux

В некоторых дистрибутивах Linux вы можете установить пакеты debuginfo , содержащие символы отладки.

В настоящее время пакеты debuginfo могут не позволить серверу распечатать красивую трассировку стека в журнале ошибок. Они также позволяют пользователям извлекать полные трассировки стека из дампов ядра. См. MDEV-20738 для получения дополнительной информации.

Установка пакетов с данными отладки с помощью yum/dnf

В RHEL, CentOS, Fedora и других аналогичных дистрибутивах Linux настоятельно рекомендуется установить соответствующий пакет RPM из репозитория MariaDB с помощью yum или dnf. Начиная с RHEL 8 и Fedora 22, yum был заменён на dnf, который является следующей основной версией yum. Однако команды yum всё ещё работают на многих системах, использующих dnf. Например:

sudo yum install MariaDB-server-debuginfo

См. Установка MariaDB с помощью yum/dnf: Установка пакетов с данными отладки с помощью YUM для получения дополнительной информации.

Установка пакетов с данными отладки с помощью zypper

В SLES, OpenSUSE и других аналогичных дистрибутивах Linux настоятельно рекомендуется установить соответствующий пакет RPM из репозитория MariaDB с помощью zypper. Например:

sudo zypper install MariaDB-server-debuginfo

См. Установка MariaDB с помощью zypper: Установка пакетов с данными отладки с помощью ZYpp для получения дополнительной информации.

Установка пакетов с данными отладки из репозитория MariaDB для Debian или Ubuntu

Это необходимо, если вы уже установили MariaDB из зеркала MariaDB.

Для Ubuntu и других репозиториев требуется дополнительный шаг:

sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el,s390x]  https://ftp.osuosl.org/pub/mariadb/repo/10.5/ubuntu focal main/debug'

Замените 10.5 на соответствующую версию, которую вы отлаживаете, и focal на требуемый дистрибутив.

apt-get update && apt-get install -y mariadb-server-core-10.5-dbgsym 

Установка пакетов с данными отладки, упакованных Ubuntu или Debian

Если вы использовали версии MariaDB, предоставленные Debian или Ubuntu, см. следующие ссылки.

Для Debian см. https://wiki.debian.org/AutomaticDebugPackages

Для Ubuntu см. https://wiki.ubuntu.com/Debug%20Symbol%20Packages

Установка символов отладки в Windows

Символы отладки доступны для установки в Windows.

Установка символов отладки с помощью установщика MSI в Windows

Символы отладки можно установить с помощью установщика MSI. Символы отладки не устанавливаются по умолчанию. Вы должны выполнить пользовательскую установку и явно выбрать установку символов отладки.

Установщик MSI можно скачать со страницы загрузки MariaDB.

Установка символов отладки с помощью пакета ZIP в Windows

MariaDB также предоставляет пакет ZIP, содержащий символы отладки в Windows.

Пакет ZIP, содержащий символы отладки, можно скачать со страницы загрузки MariaDB.

Включение дампов ядра

Чтобы включить дампы ядра, см. Включение дампов ядра для получения подробностей.

Где находится файл ядра в Linux?

В нижней части журнала ошибок будет текст о расположении файла ядра, включая:

Writing a core file...
Working directory at /var/lib/mariadb
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
...
Max core file size        unlimited            unlimited            bytes     
...
Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

Kernel version: Linux version 6.0.0-0.rc2.19.fc38.x86_64 (mockbuild@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-1), GNU ld version 2.39-2.fc38) #1 SMP PREEMPT_DYNAMIC Mon Aug 22 12:52:40 UTC 2022

Если был ограничен размер файла ядра в ресурсных ограничениях, информация о файле ядра может быть ограниченной или отсутствовать.

Если шаблон файла ядра начинается с |, то далее следует исполняемый файл, который обрабатывал файл ядра во время аварийного завершения. Ниже приведены несколько способов доступа к файлу ядра в зависимости от шаблона. Если используется другая программа, обратитесь к её справке, чтобы узнать, как получить доступ к файлу ядра.

Если в "Шаблоне файла ядра" указано просто имя файла ядра, есть большая вероятность, что он находится в текущей рабочей директории. Имя файла может иметь суффикс .{process number}.

Извлечение файла ядра из контейнера

Если вы запускаете MariaDB в контейнере, места, где может быть сгенерирован дамп ядра, ограничены. Просмотрите журналы контейнера, там, скорее всего, будет информация из журнала ошибок. Шаблон файла ядра Linux в настоящее время является фиксированным глобальным значением. Вследствие этого, если этот шаблон файла ядра относится к программе, эта программа, скорее всего, не находится в контейнере и не будет выполнена при аварийном завершении.

Системный обработчик аварийных завершений можно изменить с помощью sysctl kernel.core_pattern=core для возврата к обработке аварийных завершений на основе файлов. В таком случае аварийное завершение должно произойти в текущей рабочей директории, обычно в каталоге данных /var/lib/mysql тома контейнера.

Извлечение файла ядра из systemd-coredump

Для systemd-coredump, существует программа coredumpctl для управления доступом.

coredumpctl list
TIME                            PID   UID   GID SIG     COREFILE EXE                                                                                        >
Fri 2022-09-09 14:16:37 AEST 213571  1000  1000 SIGSEGV present  /usr/sbin/mariadbd 

Для доступа к программе с помощью gdb, coredumpctl debug (по умолчанию последний сбой), загрузит дамп ядра в gdb. Инструкции по извлечению информации находятся в следующем разделе.

См. также: извлечение дампов ядра с помощью systemd-coredump.

Извлечение файла ядра из abrt

Шаблон файла ядра |/usr/libexec/abrt-hook-ccpp указывает на использование системы abrt.

abrt-cli — это командно-строчный интерфейс для доступа к файлу ядра.

Извлечение файла ядра из apport

Шаблон файла ядра [|/usr/share/apport/apport указывает на использование apport.

Для получения дополнительной информации см. вики проекта Apport.

apport-retrace позволяет вам "Просмотреть локально" и запустить сеанс gdb. После запуска gdb можно использовать инструкции в следующем разделе для извлечения информации.

Анализ файла ядра с помощью gdb в Linux

Для анализа файла ядра в Linux можно использовать gdb.

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

sudo gdb /usr/sbin/mariadbd  /var/lib/mysql/core.932

Не забудьте заменить /usr/sbin/mariadbd на путь к вашему mariadbd двоичному файлу (может быть mysqld в MariaDB 10.4 и более ранних версиях) и также замените /var/lib/mysql/core.932 на путь к вашему файлу ядра.

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

set logging file /tmp/gdb_output.log
set logging on

Если вы не выполните set logging file, то команда set logging on создаст gdb.txt в вашей текущей рабочей директории. Перенаправление вывода в файл полезно, так как это может облегчить анализ. Это также упрощает отправку информации разработчику MariaDB, если это потребуется.

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

После завершения работы вы можете выйти из gdb, выполнив команду quit.

Получение трассировок стека с помощью gdb в Linux

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

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

Чтобы получить полную трассировку стека основного потока, вы можете выполнить следующее:

bt -frame-arguments all full

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

thread apply all bt -frame-arguments all full

Если вы хотите получить полную трассировку стека в файл для сообщения об ошибке, рекомендуемый способ – использовать gdb:

set logging on
set pagination off
set print frame-arguments all
thread apply all bt full
set logging off

Это запишет полную трассировку стека в файл gdb.txt.

Получение полных трассировок стека для всех потоков из файла ядра

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

Чтобы получить полные трассировки стека для всех потоков из файла ядра mariadbd , выполните команду, подобную следующей:

sudo gdb --batch --eval-command="set print frame-arguments all" --eval-command="thread apply all bt full" /usr/sbin/mariadbd /var/lib/mysql/core.932  > mariadbd_full_bt_all_threads.txt

Не забудьте заменить /usr/sbin/mariadbd на путь к вашему mariadbd бинарному файлу, а также заменить /var/lib/mysql/core.932 на путь к вашему дампу ядра.

Трассировки стека будут выведены в файл mariadbd_full_bt_all_threads.txt.

Получение полных трассировок стека для всех потоков из работающего mariadbd процесса

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

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

sudo gdb --batch --eval-command="set print frame-arguments all"  --eval-command="thread apply all bt full" /usr/sbin/mariadbd $(pgrep -xn mariadbd)  > mariadbd_full_bt_all_threads.txt

Не забудьте заменить /usr/sbin/mariadbd на путь к вашему mariadbd бинарному файлу.

Трассировки стека будут выведены в файл mariadbd_full_bt_all_threads.txt.

Иногда очень загруженные системы слишком загружены, чтобы получить трассировку стека. В этом случае gcore $(pidof mariadbd) может сохранить ядро и затем получить трассировку стека из дампированного ядра.

Запуск копии каталога базы данных

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

Это полезно, когда вы знаете, какая команда привела к сбою сервера.

Просто запустите mariadbd с опциями --datadir=/copy-of-original-data-directory --core-file --stack-trace --socket=/tmp/mariadbd-alone.sock --skip-networking

Отключение трассировок стека в журнале ошибок

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

[mariadb]
...
skip_stack_trace

Сообщения об ошибке

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

• Ваша полная трассировка стека.
• Ваш журнал ошибок.
• Ваши файлы опций.
• Как воспроизвести проблему.
• SHOW ENGINE INNODB STATUS
• SHOW CREATE TABLE {table (для каждой таблицы в запросе) и EXPLAIN {query}, если ошибка связана с запросом.

Доступен FTP-сервер MariaDB для больших и/или конфиденциальных данных. Загрузите в .tar.gz или .zip архив.

Для очень сложных или критических ошибок вы должны рассмотреть возможность загрузки следующей информации на FTP-сервер MariaDB:

• Ваша сборка mariadbd (если вы ее скомпилировали), в противном случае информация о версии пакета mariadb-server.
• Ваш файл ядра.
• Ваши контактные данные.
• Связанный идентификатор задачи JIRA для ошибки, если вы сообщили об ошибке.

Эта информация позволит разработчикам MariaDB Corporation проанализировать ее и попытаться создать исправление.