Dumpstack log — диагностический журнал дампа стека¶
Dumpstack log — диагностический журнал (лог), формируемый при выполнении команды или системного механизма вывода дампа стека (stack dump) процесса или ядра операционной системы. Дамп стека — это зафиксированный снимок состояния стека вызовов (call stack) в определённый момент времени, содержащий список активных функций, адреса возврата и, при соответствующей настройке, значения переменных. Записи dumpstack log используются для анализа сбоев, зависаний и некорректного завершения программ.
¶Назначение и принцип работы
Дамп стека формируется программно — по сигналу оператора, по расписанию или автоматически при возникновении исключительной ситуации (аварийном завершении, панике ядра, тайм-ауте). Полученный снимок записывается в файл журнала, который и составляет содержимое dumpstack log. Каждая запись обычно содержит:
- метку времени;
- идентификатор процесса или потока;
- имена функций в порядке их вызова (от точки сбоя к началу выполнения);
- смещения адресов внутри функций;
- при наличии — символическую информацию (имена модулей, строк исходного кода).
Формат записей зависит от платформы и инструментария. В Windows-средах дампы стека традиционно формируются утилитами procdump, adplus (из состава Debugging Tools for Windows) и средствами Windows Error Reporting. В Linux-системах аналогичную роль выполняют утилиты gdb, apport, systemd-coredump, а также механизмы ядра, записывающие трассировки в кольцевой буфер dmesg.
¶Dumpstack в Windows
В Windows-окружении термин «dumpstack» чаще всего ассоциируется с утилитой dumpstack.exe, входившей в состав Debugging Tools for Windows. Утилита выводит содержимое стека ядра (kernel stack) для процессов, выполняющихся в режиме ядра, и используется при анализе зависаний системы (так называемых «синих экранов» и фризов). Результат работы dumpstack.exe содержит цепочки вызовов модулей ядра (ntoskrnl.exe, драйверов устройств), что позволяет локализовать модуль, вызвавший блокировку или некорректное обращение к ресурсу.
Для пользовательских процессов в Windows применяется команда **~\*k в отладчике kd или cdb, а также расширение !runaway** для анализа потоков. Средства Windows Error Reporting (WER) автоматически формируют мини-дампы и полные дампы при аварийном завершении процессов, сохраняя их в каталогах %LOCALAPPDATA%\CrashDumps и %ProgramData%\Microsoft\Windows\WER.
¶Dumpstack в Linux
В Linux дампы стека ядра фиксируются средствами подсистемы трассировки. Команда echo l > /proc/sysrq-trigger (при включённом SysRq) вызывает вывод стеков всех процессов в журнал ядра. Механизм lockdep при обнаружении взаимоблокировок (deadlock) также формирует записи, содержащие цепочки вызовов, приведшие к конфликту.
При аварийном завершении пользовательских программ ядро создаёт core dump — файл, содержащий полное отображение памяти процесса. Настройки core dump управляются через /proc/sys/kernel/core_pattern. Для последующего анализа используются отладчики (gdb), загружающие core-файл и восстанавливающие стек вызовов.
Системный демон systemd-coredump (в дистрибутивах на базе systemd) централизованно собирает core-дампы, хранит их в /var/lib/systemd/coredump и позволяет просматривать их через утилиту coredumpctl.
¶Формат и структура записей
Типичная запись dumpstack log выглядит как текстовый список вызовов. Пример (упрощённо):
``` [2024-03-15 14:22:07] PID 4821, Thread 0x7f3a
¶0 0x00007f3a2c1d4e in raise (sig=6) at raise.c:54
¶1 0x00007f3a2c1f80 in abort () at abort.c:89
¶2 0x000055d2e1a3b4 in handle_error (msg=0x55d2e1b020 "segmentation fault") at main.c:214
¶3 0x000055d2e1a120 in main (argc=3, argv=0x7ffd4a2b) at main.c:57
```
Нумерация #0, #1 и далее соответствует порядку: #0 — функция, выполнявшаяся в момент снимка, последующие — вызывающие её функции. Такая структура позволяет восстановить логику исполнения и определить, на каком уровне произошёл сбой.
¶Применение
Dumpstack log находит применение в нескольких областях:
- Отладка программного обеспечения — анализ исключений и падений в ходе разработки.
- Диагностика серверов — выявление причин зависаний и деградации производительности в промышленной эксплуатации.
- Расследование инцидентов безопасности — постфактум анализ действий процесса при подозрении на компрометацию.
- Мониторинг промышленных систем — встраиваемые и SCADA-системы формируют дампы стека при сбоях для последующего анализа производителями.
¶См. также
- Дамп памяти
- Стек вызовов
- Отладчик
- Ядро операционной системы
¶Источники
- Документация Microsoft: Windows Debugging (WinDbg)
- Документация проекта GNU: GDB Manual
- Документация systemd: systemd-coredump(5)
- Linux Kernel Documentation: SysRq, lockdep