#linux #coredump
#linux #coredump
Вопрос:
Я пытался отладить ПОЛЬЗОВАТЕЛЬСКИЙ процесс в аварийном дампе Linux.
Обычными шагами для перехода к аварийному дампу являются:
- Перейдите по пути, где находится дамп.
- Используйте команду
crash kernel_link dump.201104181135.
Где kernel_link — программная ссылка, которую я создал для образа vmlinux.
Теперь вы окажетесь в приглашении к АВАРИЙНОМУ завершению. Если вы запустите команду foreach <PID Of the process> bt , например:
crash> **foreach 6920 bt**
**PID: 6920 TASK: ffff88013caaa800 CPU: 1 COMMAND: **"**climmon**"****
#0 [ffff88012d2cd9c8] **schedule** at ffffffff8130b76a
#1 [ffff88012d2cdab0] **schedule_timeout** at ffffffff8130bbe7
#2 [ffff88012d2cdb50] **schedule_timeout_uninterruptible** at ffffffff8130bc2a
#3 [ffff88012d2cdb60] **__alloc_pages_nodemask** at ffffffff810b9e45
#4 [ffff88012d2cdc60] **alloc_pages_curren**t at ffffffff810e1c8c
#5 [ffff88012d2cdc90] **__page_cache_alloc** at ffffffff810b395a
#6 [ffff88012d2cdcb0] **__do_page_cache_readahead** at ffffffff810bb592
#7 [ffff88012d2cdd30] **ra_submit** at ffffffff810bb6ba
#8 [ffff88012d2cdd40] **filemap_fault** at ffffffff810b3e4e
#9 [ffff88012d2cdda0] **__do_fault** at ffffffff810caa5f
#10 [ffff88012d2cde50] **handle_mm_fault** at ffffffff810cce69
#11 [ffff88012d2cdf00] **do_page_fault** at ffffffff8130f560
#12 [ffff88012d2cdf50] **page_fault** at ffffffff8130d3f5
RIP: 00007fd02b7e9071 RSP: 0000000040e86ea0 RFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007fd02b7e9071
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040e86ec0
RBP: 0000000040e87140 R8: 0000000000000800 R9: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff16ec43d0
R13: 00007fd02bcadf00 R14: 0000000040e87950 R15: 0000000000001000
ORIG_RAX: ffffffffffffffff CS: 0033 SS: 002b
Если вы проверите приведенную выше обратную трассировку, она покажет функции ядра, используемые для планирования / обработки сбоя страницы, но не функции, которые были выполнены в пользовательском процессе (здесь, например. climmon ).
Таким образом, я не могу отладить этот процесс, поскольку я не могу видеть функции, выполняемые в этом процессе.
Кто-нибудь может помочь мне с этим делом?
Ответ №1:
Вы не можете отлаживать процесс пользовательского пространства из аварийного дампа ядра. Если ваше ядро вышло из строя, это, скорее всего, было ошибкой ядра, а не какого-то пользовательского процесса. Ядро всегда должно вести себя должным образом, независимо от того, какой процесс пользовательского пространства выполняется на нем. Если вы хотите отладить процесс в пользовательском пространстве, я рекомендую посмотреть на ltrace, strace и gdb.
Гергели из toptal.com
Комментарии:
1. Возможно, ваша первая фраза верна, но вся оставшаяся часть вообще не имеет смысла. Я просто имею дело с системным зависанием, когда единственное, что я смог сделать (был ли я?), это запустить аварийный дамп ядра с помощью Magic SysReq. Машина отвечала на пинги, но ssh зависал. Также будет полезно посмотреть, что происходило в пользовательском пространстве (отображается список процессов), поэтому теоретически в нем также могут быть стеки пользовательского пространства. Но я понимаю соображения конфиденциальности, которые могли бы побудить авторов механизмов дампа ядра.
Ответ №2:
Я не знаю, то ли это, что вы хотите. Но вы можете попробовать аварийный вызов расширения «gcore». Он может выгружать ядро пользовательского процесса из файла сбоя ядра.
Кроме того, убедитесь, что вы включаете страницу пользователя при сбросе.
Ответ №3:
Загрузите дамп с помощью gdb: gdb vmlinux
Загрузите эти макросы gdb: http://www.kernel.org/doc/Documentation/kdump/gdbmacros.txt
(gdb) исходный код gdbmacros.txt
Используйте ‘btt’ для «сброса всех трассировок стека потоков в ядро, скомпилированное с помощью CONFIG_FRAME_POINTER».:
(gdb) btt
Используйте ‘bttnobp’ для «сброса всех трассировок стека потоков в ядре, скомпилированном с помощью !CONFIG_FRAME_POINTER»:
(gdb) bttnobp