Core dump что это
Процесс может установить свой программный предел ресурса RLIMIT_CORE в максимальное значение по размеру файла дампа, который будет создан, если процесс получит сигнал «дампа памяти»; подробней смотрите в getrlimit(2).
Есть несколько обстоятельств, при которых файл дампа памяти не создаётся:
* У процесса нет прав на запись файла дампа (по умолчанию файл дампа называется core или core.pid, где pid — ID процесса из которого делается дамп, и создаётся в текущем рабочем каталоге. Подробней об именовании смотрите далее). Запись файла дампа завершится неудачно, если каталог, в котором он создаётся, недоступен для записи, или если файл с таким же именем уже существует и недоступен для записи или это необычный файл (например, это каталог или символьная ссылка). * Существует файл (обычный, доступный на запись) с именем, которое будет использовано для дампа памяти, но есть более одной жёсткой ссылки на этот файл. * Файловая система, где должен быть создан файл дампа, переполнена, закончились иноды, она смонтирована только для чтения, достигнут предел пользовательской квоты. * Каталог, в котором должен быть создан файл дампа, не существует. * Пределы ресурсов RLIMIT_CORE (размер файла дампа) или RLIMIT_FSIZE (размер файла) для процесса установлены в ноль; смотрите getrlimit(2) и документацию на команду оболочки ulimit (limit в csh(1)). * Исполняемый процессом файл недоступен на чтение. * Процесс выполняет программу с установленными битом set-user-ID (set-group-ID), который принадлежит пользователю (группе) не совпадающей с ID реального пользователя (группы) процесса или процесс выполняется программу, имеющую файловые мандаты (смотрите capabilities(7)). Однако посмотрите описание операции prctl(2) PR_SET_DUMPABLE, и описание файла /proc/sys/fs/suid_dumpable в proc(5). * (начиная с Linux 3.7) Ядро настроено без параметра CONFIG_COREDUMP.
Также, дамп память может не содержать часть адресного пространства процесса, если в madvise(2) указан флаг MADV_DONTDUMP.
Именование файлов дампов памяти
%% одиночный символ % %c программный предел размера файла дампа рухнувшего процесса (начиная с Linux 2.6.24) %d режим дампа — тоже, как значение возвращаемое prctl(2) с PR_GET_DUMPABLE (начиная с Linux 3.7) %e имя исполняемого файла (без пути) %E путь к исполняемому файлу, в котором символы косой черты (‘/’) заменена на восклицательные знаки (‘!’) (начиная с Linux 3.0). %g (число) реальный GID процесса, с которого делается дамп %h имя узла (как nodename, возвращаемое uname(2)) %i TID нити, из-за которой возник дамп, по отношению к пространству имён PID, в котором располагается нить (начиная с Linux 3.18) %I TID нити, из-за которой возник дамп, по отношению к начальному пространству имён PID (начиная с Linux 3.18) %p PID процесса, с которого делается дамп, так как он видится в пространстве имён PID, котором расположен процесс %P initial PID процесса, с которого делается дамп, так как он видится в первоначальном пространстве имён PID, котором расположен процесс (начиная с Linux 3.12) %s номер сигнала, вызвавшего создание дампа %t время дампа, выражается в секундах с начала эпохи, 1970-01-01 00:00:00 +0000 (UTC) %u (число) реальный UID процесса, с которого делается дамп
Начиная с версии 2.4, Linux также предоставляет более примитивный метод управления именем файла дампа памяти. Если файл /proc/sys/kernel/core_uses_pid содержит значение 0, то файл дампа памяти просто называется core. Если в этом файле содержится ненулевое значение, то к имени файла дампа добавится ID процесса (в виде core.PID).
Начиная с Linux 3.6, если значение в /proc/sys/fs/suid_dumpable равно 2 («suidsafe»), то шаблон должен быть или абсолютным путём (начинаться с символа ‘/’), или каналом, как описано далее.
Передача дампов памяти в программу через канал
Управление отображениями, записываемыми в дамп памяти
Значение в файле является битовой маской типов отображений памяти (см. mmap(2)). Если бит в маске установлен, то выполняется дамп отображения памяти соответствующего типа; иначе дамп не выполняется. Биты в этом файле имеют следующее значение:
бит 0 Выполнять дамп анонимных частных отображений. бит 1 Выполнять дамп анонимных общих отображений. бит 2 Выполнять дамп частных отображений из виртуальной памяти (file-backed). бит 3 Выполнять дамп общих отображений из виртуальной памяти (file-backed). бит 4 (начиная с Linux 2.6.24) Выполнять дамп заголовков ELF. бит 5 (начиная с Linux 2.6.28) Выполнять дамп частных огромных страниц. бит 6 (начиная с Linux 2.6.28) Выполнять дамп общих огромных страниц. бит 7 (начиная с Linux 4.4) Выполнять дамп частных страниц DAX. бит 8 (начиная с Linux 4.4) Выполнять дамп общих страниц DAX.
По умолчанию, установлены следующие биты: 0, 1, 4 (если включён параметр настройки ядра CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS) и 5. Данное значение может быть изменено при запуске системы через параметр загрузки coredump_filter.
Значения этого файла отображается в шестнадцатеричной системе счисления (то есть значение по умолчанию выглядит как 33).
Для страниц ввода-вывода, отображённых в память, таких как фрейм-буфер, дамп никогда не выполняется, а виртуальные страницы DSO попадают в дамп всегда, независимо от значения coredump_filter.
Дочерний процесс, созданный fork(2), наследует значение coredump_filter родителя; значение coredump_filter сохраняется и при execve(2).
Полезно указывать значение coredump_filter в родительской оболочке до запуска программы, например:
Этот файл есть в системе только, если ядро было собрано с параметром настройки CONFIG_ELF_CORE.
ЗАМЕЧАНИЯ
В версии Linux до 26.27 включительно, если для многонитевого процесса (или, точнее, процесса, который делит свою памяти с другим процессом, созданным с флагом CLONE_VM через clone(2)) выполняется дамп памяти, то ID процесса всегда добавляется к имени файла дампа, если ID процесса уже не включён в это имя с помощью %p в /proc/sys/kernel/core_pattern (это, главным образом, полезно когда применяется устаревшая реализация LinuxThreads, где каждая нить процесса имеет свой PID).
Core dump
A core dump is a file containing a process’s address space (memory) when the process terminates unexpectedly. Core dumps may be produced on-demand (such as by a debugger), or automatically upon termination. Core dumps are triggered by the kernel in response to program crashes, and may be passed to a helper program (such as systemd-coredump) for further processing. A core dump is not typically used by an average user, but may be passed on to developers upon request where it can be invaluable as a post-mortem snapshot of the program’s state at the time of the crash, especially if the fault is hard to reliably reproduce.
Contents
Disabling automatic core dumps
Users may wish to disable automatic core dumps for a number of reasons:
Using sysctl
sysctl can be used to set the kernel.core_pattern to nothing to disable core dump handling. Create this file
To apply the setting immediately, use sysctl :
Using systemd
Then reload systemd’s configuration.
This method alone is usually sufficient to disable userspace core dumps, so long as no other programs enable automatic core dumps on the system, but the coredump is still generated in memory and systemd-coredump run.
Using PAM limits
The maximum core dump size for users logged in via PAM is enforced by limits.conf. Setting it to zero disables core dumps entirely. [3]
Using ulimit
Command-line shells such as bash or zsh provide a builtin ulimit command which can be used to report or set resource limits of the shell and the processes started by the shell. See bash(1) § SHELL BUILTIN COMMANDS or zshbuiltins(1) for details.
To disable core dumps in the current shell:
Making a core dump
To generate a core dump of an arbitrary process, first install the gdb package. Then find the PID of the running process, for example with pgrep:
Attach to the process:
Then at the (gdb) prompt:
Where do they go?
Examining a core dump
Use coredumpctl to find the corresponding dump:
Pay attention to «Signal» row, that helps to identify crash cause. For deeper analysis you can examine the backtrace using gdb:
When gdb is started, use the bt command to print the backtrace:
See Debugging/Getting traces if debugging symbols are requested, but not found.
Файлы дампа
Сбор дампов
Дампы можно собирать различными способами в зависимости от того, на какой платформе вы используете приложение.
Дампы могут содержать конфиденциальные сведения, поскольку они могут содержать всю память выполняющегося процесса. При их обработке следует учитывать ограничения безопасности и рекомендации.
Сбор дампов при сбое
Вы можете использовать переменные среды, чтобы настроить приложение на сбор дампа при сбое. Это полезно, если вы хотите получить представление о причинах сбоя. Например, запись дампа при возникновении исключения помогает выявить проблемы путем проверки состояния приложения при его сбое.
В следующей таблице приведены переменные среды, которые можно настроить для сбора дампов при сбое.
| Переменная среды | Описание | Значение по умолчанию |
|---|---|---|
| COMPlus_DbgEnableMiniDump или DOTNET_DbgEnableMiniDump | Если задано значение 1, включите создание дампа ядра. | 0 |
| COMPlus_DbgMiniDumpType или DOTNET_DbgMiniDumpType | Тип собираемого дампа. Дополнительные сведения см. в таблице ниже. | 2 ( MiniDumpWithPrivateReadWriteMemory ) |
| COMPlus_DbgMiniDumpName или DOTNET_DbgMiniDumpName | Файл, в который записывается дамп. | /tmp/coredump. |
| COMPlus_CreateDumpDiagnostics или DOTNET_CreateDumpDiagnostics | Если задано значение 1, включите ведение журнала диагностики для процесса дампа. | 0 |
| Значение | Имя | Описание |
|---|---|---|
| 1 | MiniDumpNormal | Включение только сведений, необходимых для записи трассировок стека для всех существующих потоков в процессе. Ограниченная память кучи сборки мусора и информация. |
| 2 | MiniDumpWithPrivateReadWriteMemory | Включение кучи сборки мусора и сведений, необходимых для записи трассировок стека для всех существующих потоков в процессе. |
| 3 | MiniDumpFilterTriage | Включение только сведений, необходимых для записи трассировок стека для всех существующих потоков в процессе. Ограниченная память кучи сборки мусора и информация. |
| 4 | MiniDumpWithFullMemory | Включение в процесс всей доступной памяти. Необработанные данные памяти включаются в конец, чтобы начальные структуры можно было сопоставить напрямую без необработанных данных памяти. Этот вариант может привести к созданию очень большого файла. |
Сбор дампов в определенный момент времени
Вы можете собрать дамп, когда приложение еще не завершило работу. Например, если вы хотите проверить состояние приложения, в котором, на ваш взгляд, возникла взаимоблокировка, настройка переменных среды для сбора дампов при сбое не будет полезна, так как приложение все еще работает.
Анализ дампов
Дампы можно проанализировать с помощью средства CLI dotnet-dump или Visual Studio.
Если необходима отладка машинного кода, можно использовать расширение отладчика SOS совместно с LLDB в Linux и macOS. SOS также поддерживается в Windows c Windbg/cdb, хотя рекомендуется использовать Visual Studio.
См. также раздел
В руководстве по отладке дампов Linux представлены пошаговые инструкции по отладке дампа, собранного в Linux.
Русские Блоги
Конфигурация coredump, генерация, анализ и примеры анализа
Ключевые слова: coredump、core_pattern、coredump_filter и многое другое.
Приложение завершается из-за различных исключений или ошибок во время выполнения процесса, и файл ядра создается при выполнении определенных условий.
Обычно основной файл содержит память, состояние регистра, указатель стека, информацию об управлении памятью и информацию о стеке вызовов функций во время работы программы.
1. Настройте coredump.
в состоянии пройти /proc/sys/kernel/core_pattern Сделайте настройки.
Через echo «core-% e-% p-% s-% t»> / proc / sys / kernel / core_pattern.
Под каждым процессом есть узел coredump_filter. /proc/
Настроив coredump_filter, вы можете выбрать, какой контент выгрузить в основной файл во время coredump.
coredump_filter может быть унаследован дочерними процессами.Вы можете ввести 0xXX> / proc / self / coredump_filter, чтобы установить coredump_filter текущего процесса.
Среди них MMF_DUMP_FILTER_SHIFT равно 2, поэтому flags и coredump_filter имеют следующее соответствие.
2. Принцип coredump
В do_signal () судите, запускать ли coredump в соответствии с сигналом, конечно, это также связано с пределом coredump, флагами mm-> и так далее.
После выполнения условия coredump файл coredump генерируется do_coredump (), а ядро генерируется binfmt-> core_dump ().
2.1 Каковы условия запуска coredump?
Когда ядро вернется в пользовательское пространство, оно вызоветdo_signal() Обработка сигнала.
#define SIG_KERNEL_COREDUMP_MASK (\
rt_sigmask(SIGQUIT) | rt_sigmask(SIGILL) | \
rt_sigmask(SIGTRAP) | rt_sigmask(SIGABRT) | \
rt_sigmask(SIGFPE) | rt_sigmask(SIGSEGV) | \
rt_sigmask(SIGBUS) | rt_sigmask(SIGSYS) | \
rt_sigmask(SIGXCPU) | rt_sigmask(SIGXFSZ) | \
SIGEMT_MASK )
В get_signal () определите, вызовет ли сигнал coredump. Эти сигналы включают SIGQUIT、SIGILL、SIGTRAP、SIGABRT、SIGFPE、SIGSEGV、SIGBUS、SIGSYS、SIGXCPU、SIGXFSZ 。
2.2 Как сгенерировать coredump?
Ядро linux поддерживает множество linux_binfmt, наиболее часто используемым здесь является ELF. К
Или судите через файловую команду.
3. Случай Coredump
Давайте создадим простой пример создания coredump, а затем проанализируем его с помощью gdb.
3.1 пример coredump
3.2 coredump + анализ gdb
Для более детального анализа методов core + gdb, пожалуйста, обратитесь к «Автономный анализ через core + gdb», вам необходимо загрузить динамическую библиотеку в процессе анализа, вы можете обратиться к»Путь поиска динамической библиотеки GDB》。
4. Резюме
Пока что, наверное, резюмировал настройки coredump ( ulimit/core_pattern/coredump_filter )? Условия, запускающие coredump ( SIG_KERNEL_COREDUMP_MASK )? Coredump генерирует основной файловый процесс ( do_coredump () )? Как GDB распознает файлы ядра ( 《 Как GDB восстанавливает информацию динамической библиотеки из файла Coredump 》 )? Как использовать gdb для анализа файлов ядра и поиска проблем ( gdb->backtrace )？
Использование дампов ядра для диагностики сбойных программ
Дампы ядра часто применяются для диагностики и поиска ошибок в Линуксовых и Юниксовых программах. Они помогут системному администратору выяснить, отчего рухнула та или иная программа, например, Lighttpd, Apache или PHP-CGI. Файл дампа ядра генерируется всякий раз, когда программа нештатно завершается из-за ошибки, нарушения политики безопасности операционной системы, попытки записывать данные вне отведенной ей области памяти и так далее. В этой статье рассказано, как подключить генерацию файлов дампов ядра и отслеживать с их помощью ошибки в программах.
Как подключить создание файлов дампа ядра
Как просмотреть текущие настройки файлов дампа ядра
Нулевой вывод команды означает, что файлы дампов не создаются.
Как изменить настройки
Как подключить генерацию файлов дампа ядра для рухнувших программ и ошибок сегментации
Найдите в /etc/profile строку
И измените ее, чтобы получилось:
Также следует внести изменения в файл /etc/sysctl.conf. В этот файл следует дописать три строки:
Не забудьте сохранить отредактированные файлы.
Что означают последние три записи?
Совершив все вышеописанные действия, запустите дампирование при помощи команды (Redhat и подобные дистрибутивы):
И запишите настройки в /etc/sysctl.conf при помощи следующей команды:
Как инициировать создание дампов ядра для конкретного демона
Например, для демона lighttped, в файл /etc/init.d/lighttped нужно добавить строку:
Сохраните файл. Затем перезапустите демон:
Правильный вывод последней команды:
Имейте в виду, что эта вышеприведенная строка является специфичной только для Redhat. Для всех остальных дистрибутивов конфигурацию прописывают строками:
Все, теперь можно отправлять дамп ядра разработчикам или распространителям программы.
