Чем открыть coredump linux

Использование дампов ядра для диагностики сбойных программ

Дампы ядра часто применяются для диагностики и поиска ошибок в Линуксовых и Юниксовых программах. Они помогут системному администратору выяснить, отчего рухнула та или иная программа, например, Lighttpd, Apache или PHP-CGI. Файл дампа ядра генерируется всякий раз, когда программа нештатно завершается из-за ошибки, нарушения политики безопасности операционной системы, попытки записывать данные вне отведенной ей области памяти и так далее. В этой статье рассказано, как подключить генерацию файлов дампов ядра и отслеживать с их помощью ошибки в программах.

Как подключить создание файлов дампа ядра

Как просмотреть текущие настройки файлов дампа ядра

Нулевой вывод команды означает, что файлы дампов не создаются.

Как изменить настройки

Как подключить генерацию файлов дампа ядра для рухнувших программ и ошибок сегментации

Найдите в /etc/profile строку

И измените ее, чтобы получилось:

Также следует внести изменения в файл /etc/sysctl.conf. В этот файл следует дописать три строки:

Не забудьте сохранить отредактированные файлы.

Что означают последние три записи?

kernel.core_uses_pid = 1 ≈ добавляет к имени файла дампа номер PID процесса.

fs.suid_dumpable = 2 ≈ обеспечивает создание дампов ядра для программ с setuid битом.

kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t ≈ Когда программа нештатно завершается, файл дампа появляется в директории /tmp. Благодаря параметру kernel.core_pattern, программа sysctl определяет конкретное имя файла дампа ядра. При помощи символа процента (%) могут быть заданы следующие значения:

• %% ≈ одиночный символ %
• %p ≈ PID дампируемого процесса
• %u ≈ UID дампируемого процесса
• %g ≈ GID дампируемого процесса
• %s ≈ Номер сигнала, вызвавшего дампирование
• %t ≈ время создания дампа (в секундах, с момента 0:00часов, 1 января 1970, то есть с условного момента создания ОС Юникс)
• %h ≈ hostname (имя хоста), также как и ‘nodename’, возвращаемое командой uname(2)
• %e ≈ имя исполняемого файла программы

Совершив все вышеописанные действия, запустите дампирование при помощи команды (Redhat и подобные дистрибутивы):

И запишите настройки в /etc/sysctl.conf при помощи следующей команды:

Как инициировать создание дампов ядра для конкретного демона

Например, для демона lighttped, в файл /etc/init.d/lighttped нужно добавить строку:

Сохраните файл. Затем перезапустите демон:

Правильный вывод последней команды:

Имейте в виду, что эта вышеприведенная строка является специфичной только для Redhat. Для всех остальных дистрибутивов конфигурацию прописывают строками:

Все, теперь можно отправлять дамп ядра разработчикам или распространителям программы.

Источник

Куда записываются Core dump-ы?

программа при старте выдала сообщение:

Мои вопросы:
1) кто записывает core-dump-ы? Какой-то модуль ядра? Какой?
man systemd-coredump
2) куда записываются core-dump-ы? (в какую директорию)

что-то не похоже:

я не умею пользоваться gdb, что делать дальше?

Смотреть gdb (ключ -c) совместно с исполняемым файлом программы, получившей сигнал.

Погоди, а зачем тебе кордамп тогда?

ну я думал, что мне посоветуют какую-нибудь огромную IDE, я её запущу и мне всё объяснят, что произошло и из-за чего возникла ошибка.

Переходи на Java, там всё как ты хочешь.

Ну, нет. Программа, к тому же, должна была бы быть скомпилена с дебаг-символами, а у тебя, похоже, не этот случай.

Я добавлял ключ -as в командную строку as

-a[cdghlmns] Turn on listings, in any of a variety of ways: -as include symbols

и файл у меня не обрезаный:

я не умею пользоваться gdb, что делать дальше?

Учиться пользоваться gdb.

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

Да ещё и ассемблер… Непонятен use case, в общем.

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

Гугл буквально первым результатом выдаёт подробную инструкцию об отладке программ на ассемблере. Сегодня я так узнал, что GNU assembler умеет писать достаточно отладочной информации, чтобы отлаживаясь, можно было ходить по строчкам с помощью s , а не si .

Но там на английском, а его ТС наотрез отказывается учить.

Гугл буквально первым результатом выдаёт

Источник

Как просмотреть файл CoreDump?

Когда вы сообщаете об ошибке при сбое, ошибка сделана частной и файл CoreDump.gz. Документация Bug Triage гласит следующее:

Если в результате сбоя все еще есть вложение CoreDump.gz, невозможно автоматически получить полностью символическую трассировку стека и проверить наличие дубликатов.

Stacktrace.txt кажется читаемым человеком. Как я могу понять смысл трассировки стека. CoreDump с CoreDump.gz не кажется читаемым человеком. Что такое «полностью символическая трассировка стека»? В чем разница между «полностью символической трассировкой стека» Как просмотреть содержимое файла CoreDump? (попробовал «кот», но он не чист)

1 ответ

Coredump.gz — это (сжатая) память, доступная для программы, которая разбилась. Это двоичный файл.

Coredumps можно просмотреть, запустив «gdb»:

Конечно, вам все равно понадобится пакеты отладки, связанные с этим ядром.

Затем вы можете сгенерировать stacktrace с помощью:

для создания stacktrace текущего потока — без разрешения параметра — , или

для создания stacktrace всех потоков в coredump, с разрешением параметров.

stacktrace и fulltools показывают поток управления внутри программы. Для Python вершина stacktrace показывает самый старый вызов с самым последним внизу; для почти всего остального, верхний — это самый последний вызов, а нижний — самый старый.

Полная функция stacktrace не только покажет поток, но и значения параметра. Здесь мы обычно находим частные данные — например, вы видите функцию, называемую «validatePassword» с параметром «Пароль», а значение «MySecretPassword» .

Stacktraces обычно только полезно, если пакеты отладки установлены (так что фреймы стека могут быть разрешены во что-то, что мы можем легко прочитать). Анализ stacktrace потребует наличия источников, которые были использованы для создания этого конкретного экземпляра программы.

Источник

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

При падении приложения оно создаёт core-файл, который можно проанализировать. За создание core файлов отвечает утилита coreadm. С её помощью можно указать, где будут лежать core-файлы, для каких типов создавать core-файлы и т.д.

Важно понимать, что core dump файлы системы и процессов отличаются, и их нужно анализировать по разному.

coreadm

Данная команда введённая без параметров выведет текущие настройки:

Для того, что бы начать использовать coreadm установим путь, где будут храниться наши core-файлы:

#coreadm -g /var/cores/core.%f.%p

Далее выберем то, что хотим что бы попадало в core-файл:

#coreadm -G content

Возможные значения для content (оставлю без перевода, что бы не терялся смысл):

— ctf: CTF type information sections for loaded object files
— data: Writable private file mappings — dism: DISM mappings
— heap: Process heap
— ism: ISM mappings
— rodata: Read-only private file mappings
— shanon: Anonymous shared mappings
— shfile: Shared mappings that are backed by files
— shm: System V shared memory
— stack: Process stack
— symtab: Symbol table sections for loaded object files
— text: Readable and executable private file mappings

Либо просто указать all что бы попадало всё.
Есть ещё опции -e/-d которые означают включить/выключить определённые параметры.
Напомню, что coreadm управляется через SMF сервис svc:/system/coreadm:default. Так же можно отметить, что все изменения сохраняются в файле /etc/coreadm.conf

Правда частенько системные администраторы отключают создание core-файлов для процессов

coreadm -d process

так как они могут генерить большие объёмы данных.

При отлавливании багов лучше всего включать создание всех

Отдельно хочется отметить команду

которая позволит регистрировать в логах появление core-файлов

dumpadm

Данная команда управляет параметрами системного crash dump’a. Управляется она тоже через SMF — svc:/system/dumpadm:default и работает через устройство /dev/dump. Команда без параметров выведет текущие настройки:

savecore/gcore

Эта утилита служит для сохранения core dump файлов. Ею очень удобно сбрасывать в дамп текущее состояние системы:

# savecore -L
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
0:03 100% done
100% done: 128815 pages dumped, dump succeeded
savecore: System dump time: Fri Apr 27 19:46:16 2012
savecore: Saving compressed system crash dump in /var/crash/vmdump.1
savecore: Decompress the crash dump with
‘savecore -vf /var/crash/vmdump.1’

# gcore $$
gcore: core.2770 dumped

Для того, чтобы проанализировать дамп, можно восстановить его в привычном виде:

# savecore -vf /var/crash/vmdump.1
savecore: System dump time: Fri Apr 27 19:46:16 2012
savecore: saving system crash dump in /var/crash/.1
Constructing namelist /var/crash/unix.1
Constructing corefile /var/crash/vmcore.1
0:12 100% done: 128815 of 128815 pages saved
3481 (2%) zero pages were not written
0:12 dump decompress is done

Анализ core dump-файлов.

Для анализа можно использовать отладчик mdb. Вот небольшой пример использования

# /usr/bin/mdb -k unix.0
Loading modules: [ unix krtld genunix ip nfs ipc ptm ]
> ::status
debugging crash dump /dev/mem (64-bit) from ozlo
operating system: 5.10 Generic sun4v
> ::system
set ufs_ninode=0x9c40 [0t40000]
set ncsize=0x4e20 [0t20000]
set pt_cnt=0x400 [0t1024]

Очень хорошо анализ core dump файлов описаны здесь

http://solaristhings.blogspot.com/2006/08/dont-be-afraid-of-mdb.html
http://kristof.willen.be/node/1100
http://www.c0t0d0s0.org/archives/4391-Less-known-Solaris-Features-About-crashes-and-cores.html
http://www.cuddletech.com/blog/pivot/entry.php?id=965
http://www.cuddletech.com/blog/pivot/entry.php?id=966
http://eteck.blogspot.com/2012/04/solaris-crash-dump-anylysis.html

Анализ 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 /usr/php54/sbin/php-fpm ./core.php-fpm.23922
.
Reading symbols from /lib/amd64/libelf.so.1. done.
Loaded symbols for /lib/64/libelf.so.1
Reading symbols from /usr/lib/security/amd64/pkcs11_kernel.so.1. done.
Loaded symbols for /usr/lib/security/64/pkcs11_kernel.so.1
Reading symbols from /lib/amd64/ld.so.1. done.
Loaded symbols for /lib/amd64/ld.so.1
Core was generated by `/usr/php54/sbin/php-fpm -y /usr/php54/etc/php-fpm.conf’.
Program terminated with signal 11, Segmentation fault.
[New process 89458 ]
#0 0x000000000093f2eb in zend_fetch_var_address_helper_SPEC_CONST_VAR ()
(gdb) bt
#0 0x000000000093f2eb in zend_fetch_var_address_helper_SPEC_CONST_VAR ()
#1 0x0000000000938c81 in execute ()
#2 0xfffffd7f923747b7 in xdebug_execute () from /usr/php54/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
#3 0x00000000009394c7 in zend_do_fcall_common_helper_SPEC ()
#4 0x0000000000938c81 in execute ()
#5 0xfffffd7f923747b7 in xdebug_execute () from /usr/php54/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
#6 0x00000000008fa118 in zend_call_function ()
#7 0x00000000009222b1 in zend_call_method ()
#8 0x00000000007d0672 in zif_spl_autoload_call ()
#9 0x00000000008fa080 in zend_call_function ()
#10 0x00000000008fa8d4 in zend_lookup_class_ex ()
#11 0x000000000091170f in zend_is_callable_check_class ()
#12 0x0000000000912811 in zend_is_callable_ex ()
#13 0x00000000008f9605 in zend_call_function ()
#14 0x00000000008f93f3 in call_user_function_ex ()
#15 0x00000000008f92e7 in call_user_function ()
#16 0x00000000007c16d4 in ps_call_handler ()
#17 0x00000000007c1c0a in ps_write_user ()
#18 0x00000000007b8edf in php_session_save_current_state ()
#19 0x00000000007be9e8 in zm_deactivate_session ()
#20 0x0000000000910c1a in zend_deactivate_modules ()
#21 0x0000000000898073 in php_request_shutdown ()
#22 0x00000000009859b1 in main ()
(gdb) where
#0 0x000000000093f2eb in zend_fetch_var_address_helper_SPEC_CONST_VAR ()
#1 0x0000000000938c81 in execute ()
#2 0xfffffd7f923747b7 in xdebug_execute () from /usr/php54/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
#3 0x00000000009394c7 in zend_do_fcall_common_helper_SPEC ()
#4 0x0000000000938c81 in execute ()
#5 0xfffffd7f923747b7 in xdebug_execute () from /usr/php54/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
#6 0x00000000008fa118 in zend_call_function ()
#7 0x00000000009222b1 in zend_call_method ()
#8 0x00000000007d0672 in zif_spl_autoload_call ()
#9 0x00000000008fa080 in zend_call_function ()
#10 0x00000000008fa8d4 in zend_lookup_class_ex ()
#11 0x000000000091170f in zend_is_callable_check_class ()
#12 0x0000000000912811 in zend_is_callable_ex ()
#13 0x00000000008f9605 in zend_call_function ()
#14 0x00000000008f93f3 in call_user_function_ex ()
#15 0x00000000008f92e7 in call_user_function ()
#16 0x00000000007c16d4 in ps_call_handler ()
#17 0x00000000007c1c0a in ps_write_user ()
#18 0x00000000007b8edf in php_session_save_current_state ()
#19 0x00000000007be9e8 in zm_deactivate_session ()
#20 0x0000000000910c1a in zend_deactivate_modules ()
#21 0x0000000000898073 in php_request_shutdown ()
#22 0x00000000009859b1 in main ()

Очень удобно так же запустить программу через gdb:

Источник