Как посмотреть core dump linux
Обновлено: 06.07.2024
При падении приложения оно создаёт core-файл, который можно проанализировать. За создание core файлов отвечает утилита coreadm. С её помощью можно указать, где будут лежать core-файлы, для каких типов создавать core-файлы и т.д.
Важно понимать, что core dump файлы системы и процессов отличаются, и их нужно анализировать по разному.
coreadm
Данная команда введённая без параметров выведет текущие настройки:
Для того, что бы начать использовать coreadm установим путь, где будут храниться наши core-файлы:
Далее выберем то, что хотим что бы попадало в core-файл:
Возможные значения для content (оставлю без перевода, что бы не терялся смысл):
Либо просто указать all что бы попадало всё.
Есть ещё опции -e/-d которые означают включить/выключить определённые параметры.
Напомню, что coreadm управляется через SMF сервис svc:/system/coreadm:default. Так же можно отметить, что все изменения сохраняются в файле /etc/coreadm.conf
Правда частенько системные администраторы отключают создание core-файлов для процессов
coreadm -d process
так как они могут генерить большие объёмы данных.
При отлавливании багов лучше всего включать создание всех
Отдельно хочется отметить команду
которая позволит регистрировать в логах появление core-файлов
dumpadm
savecore/gcore
Эта утилита служит для сохранения core dump файлов. Ею очень удобно сбрасывать в дамп текущее состояние системы:
Для того, чтобы проанализировать дамп, можно восстановить его в привычном виде:
Анализ core dump-файлов.
Для анализа можно использовать отладчик mdb. Вот небольшой пример использования
Очень хорошо анализ core dump файлов описаны здесь
Анализ core файлов.
Небольшой пример анализа core файла:
$ ./a.out
Segmentation Fault(coredump)
$ /usr/proc/bin/pstack ./core
core './core' of 19305: ./a.out
000108c4 main (1, ffbef5cc, ffbef5d4, 20800, 0, 0) + 1c
00010880 _start (0, 0, 0, 0, 0, 0) + b8
Очень удобно анализировать через gdb, но он не входит в базовую систему и его придётся доставлять отдельно.
Смотреть gdb (ключ -c) совместно с исполняемым файлом программы, получившей сигнал.
Погоди, а зачем тебе кордамп тогда?
ну я думал, что мне посоветуют какую-нибудь огромную IDE, я её запущу и мне всё объяснят, что произошло и из-за чего возникла ошибка.
Переходи на Java, там всё как ты хочешь.
Ну, нет. Программа, к тому же, должна была бы быть скомпилена с дебаг-символами, а у тебя, похоже, не этот случай.
Я добавлял ключ -as в командную строку as
-a[cdghlmns] Turn on listings, in any of a variety of ways: -as include symbols
и файл у меня не обрезаный:
Последнее исправление: Einstok_Fair 07.07.18 16:16:38 (всего исправлений: 1)
я не умею пользоваться gdb, что делать дальше?
Учиться пользоваться gdb.
Ну уж нет! И вообще, я же тебя неоднократно просил в мои треды не отвечать. Тут даже тегов твоих любимых нет.
Да ещё и ассемблер… Непонятен use case, в общем.
Это нормально. Каждый раз когда я пишу на LOR, вам всегда ничего непонятно, всегда вы хотите в чужой карман залезть.
Гугл буквально первым результатом выдаёт подробную инструкцию об отладке программ на ассемблере. Сегодня я так узнал, что GNU assembler умеет писать достаточно отладочной информации, чтобы отлаживаясь, можно было ходить по строчкам с помощью s , а не si .
Возникла необходимость получить дамп РНР-процесса на Debian 9.
Рассмотрим механизм ядра, позволящий создать дамп, и настройку создания дампов в Linux.
Linux Core Dump
Ядро создаёт дамп памяти процесса, если он выполнил недопустимую операцию, и должен быть остановлен.
Для этого при выполнении такой операции ядро отправляет один из аварийных сигналов процессу, после чего процесс обрабатывает сигнал сам, или с помощью сторонних обработчиков, что запускает механизм ядра, который создаёт дамп.
Список таких сигналов задаётся в макросе SIG_KERNEL_COREDUMP_MASK :
Который срабывает в случае Fatal-ошибок, и вызывает do_coredump() :
Ну а сама do_coredump() создаёт дамп.
Сигналы и создание дампа
Проверим работу дампа.
Берём простой код на Си:
Собираем, и запускаем:
В окне с приложением проверяем:
Проверяем файл дампа:
-rw------- 1 setevoy setevoy 380928 Mar 10 11:24 coredump-make_dump.2714790 /tmp/coredump-sleep.2761144: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'sleep 100', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/sleep', platform: 'x86_64' Program terminated with signal SIGSEGV, Segmentation fault. 0 0x00007f50d566e27e in clock_nanosleep@GLIBC_2.2.5 () from /usr/lib/libc.so.6kernel.core_pattern
Тут можно задать путь и имя файла, в который будет записан дамп, либо передать создание дампа внешнему обработчику, например systemd-coredump (рассмотрим ниже).
См. документацию Naming of core dump files тут>>>.
Из наиболее используемых опций тут:
- %e executable filename (without path prefix)
- %p PID of dumped process, as seen in the PID namespace in which the process resides
- %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)
Собственно файл /tmp/coredump-make_dump.2714790, который мы открыли в GDB, и состоит из kernel.core_pattern = /tmp/coredump-%e.%p :
limits.conf
Либо проверяем в рабочем окружении:
Лимиты конкретного процесса можно получить через его дескриптор в /proc :
fs.suid_dumpable
Иногда дамп может не создаваться, если процесс в процессе выполнения выполнил запрос на смену UID, например через вызов setuid() .
Определяется флагом fs.suid_dumpable :
Может принимать значение 0, 1 или 2, см. man proc:
systemd-coredump
На Arch Linux он используется по-умолчанию, на Debian 9 ставим из репозитория:
|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %eСоздаём дамп какого-то процесса:
coredumpctl
Mon 2020-03-09 20:10:16 EET 20882 0 0 11 present /home/admin/dump_test Tue 2020-03-10 09:04:14 EET 16786 1003 1003 11 present /usr/sbin/php-fpm7.4 Tue 2020-03-10 12:23:43 EET 27117 0 0 11 present /bin/sleepВ колонке SIG сразу видим код сигнала, с которым был убит процесс, в данном случае 11 == SIGSEGV .
Сами файлы дампов systemd-coredump сохраняет в /var/lib/systemd/coredump :
-rw-r----- 1 root root 25208 Mar 9 20:10 core.dump_test.0.6bb23c691d354e9dbf4382d109a5c1d4.20882.1583777416000000000000.lz4 -rw-r----- 1 root root 33962 Mar 10 12:23 core.sleep.0.6bb23c691d354e9dbf4382d109a5c1d4.27117.1583835823000000000000.lz4Core Dump также называется core dump. Если во время работы программы возникает исключение, сохраните данные ее памяти в файл. Этот процесс называется Core Dump. Ядро относится к памяти, которая сейчас является памятью.
3. Какая польза от Core Dump?
В процессе разработки вы неизбежно столкнетесь с ненормальным выходом во время работы программы. В настоящее время, если вы хотите определить, что не так, зачастую недостаточно полагаться на собственную печать программы (ведение журнала). В настоящее время требуется Core Dump. Файл здесь, чтобы помочь.
Полный файл Core Dump фактически эквивалентен восстановлению ненормальной сцены. С файлом Core Dump вы можете просматривать всю информацию, когда программа ненормальная, значения переменных, информацию стека, данные в памяти и положение запуска, когда программа ненормальная (даже запись строки кода) Нет.) И т. Д. Всю информацию, необходимую для позиционирования, можно получить из файла Core Dump, который может эффективно повысить эффективность позиционирования.
Генерация Core Dump часто вызвана тем, что система запускает сигнал выхода из-за ненормальной программы. Например, общая ошибка сегментации (ядро сброшено).
4. Как генерировать Core Dump?
В Linux установите
Вы можете включить основной файл. Фактически, включить или отключить основной файл можно, установив ограничение размера основного файла.
Используйте команду ulimit -a для просмотра связанных атрибутов.
Чтобы убедиться, что Coredump генерируется при сбое программы под Linux, обратите внимание на следующие проблемы:
1. Убедитесь, что каталог, в котором хранится Coredump, существует и что процесс имеет разрешение на запись в каталог. Каталог, в котором хранится Coredump, является текущим каталогом процесса, который обычно является каталогом, в котором была введена команда для запуска процесса. Но если он запускается сценарием, сценарий может изменить текущий каталог, тогда реальный текущий каталог процесса будет отличаться от каталога, в котором сценарий был первоначально выполнен. В настоящее время вы можете просмотреть цель символьной ссылки "/ proc / process pid> / cwd", чтобы определить реальный текущий адрес каталога процесса. Процессы, запущенные через системные службы, также можно просматривать таким образом.
Во-вторых, если программа вызывает seteuid () / setegid (), чтобы изменить действующего пользователя или группу процесса, система не будет генерировать Coredump для этих процессов по умолчанию. Многие сервисные программы будут вызывать seteuid (), например MySQL, независимо от того, какого пользователя вы используете для запуска mysqld_safe для запуска MySQL, эффективным пользователем mysqld всегда является пользователь msyql. Если вы изначально запускали программу с пользователем A, но пользователь программы, которую вы видели в ps, был B, тогда эти процессы назывались seteuid. Чтобы эти процессы могли генерировать дампы ядра, вам нужно изменить содержимое файла / proc / sys / fs / suid_dumpable на 1 (обычно по умолчанию 0).
5. Где генерируется файл Core Dump?
Вы можете использовать следующую команду: cat / proc / sys / kernel / core-pattern для просмотра пути генерации и формата файла Core Dump.
Файл Core Dump по умолчанию является core. В некоторых версиях Linux сгенерированный файл core имеет номер процесса, например core.7715.
также может быть установлен в следующем формате: core-%e-%p-%t
где% e представляет имя программы,% p представляет PID процесса, а% t представляет время, когда запускается дамп ядра (в секундах, рассчитывается с 1970-01-01 00:00:00) ,
6. Как использовать файлы Core Dump?
Вы можете использовать gdb в Linux для отладки и анализа файлов Core Dump.
После завершения загрузки вы можете просмотреть различную информацию о работе, когда программа работает в GDB ненормально (просмотреть значения переменных, информацию о потоках, стек вызовов, разборку и т. Д.)
Команда отладки может использовать where или bt (backtrace) для просмотра информации стека при сбое программы.
7. Анализ ситуации
Скомпилируйте и сгенерируйте исполняемый файл: gcc TEST_DUMP.c -o test_dump
Run./test_dump
Результат теста:
анализ:
Сгенерированный основной файл:
gdb ./test_dump core
Отладка GDB выглядит следующим образом:
Читайте также: