Segmentation fault seen while decoding ARM64 kdump. #176
Comments
codernavi18
changed the title
|
Here's the backtrace of the crash : |
|
The kernel module being loded is a dummy kernel module that just have a null pointer deference in the init function, to trigger a kernel panic intentionally. The debug symbols are present. |
Interesting, the above code shouldn't cause any segfault, except the sp is an invalid pointer. Could you please print the value of sp out? In addition, if sp is a valid pointer, then I guess the line printed here isn't the real place where segfault happens. In this case, you can rebuild crash utility source code without any compiling optimization. To do this, in crash source code, "make target=ARM64" to compile crash for the first time, then "make clean && make target=ARM64" to clean up and make the 2nd time. There won't be compiling optimization for the 2nd time :). Then re-test and post your findings here. If none of these can work for you, it will be OK to send your vmcore/vmlinux to me via google drive or any other sharing method by private email if the vmcore shouldn't open to public, so I can have a look myself. Thanks,
|
|
Sorry my bad. I forgot to mention that the The kernel uImage is built from vanilla 6.5 linux kernel release, built for arm64 using defconfig. The module just has two lines of code in init to trigger null pointer deference and when this module is loaded, the kdump is triggered. The |
|
Patch posted upstream1, it can work according to my test. Thanks for your bug reporting and vmcore providing! |
The following segmentation fault occurred during session initialization: $ crash vmlinx vmcore ... please wait... (determining panic task)Segmentation fault Here is the backtrace of the crash-utility: (gdb) bt #0 value_search_module_6_4 (value=18446603338276298752, offset=0x7ffffffface0) at symbols.c:5564 crash-utility#1 0x0000555555812bd0 in value_to_symstr (value=18446603338276298752, buf=buf@entry=0x7fffffffb9c0 "", radix=10, radix@entry=0) at symbols.c:5872 crash-utility#2 0x00005555557694a2 in display_memory (addr=<optimized out>, count=2048, flag=208, memtype=memtype@entry=1, opt=opt@entry=0x0) at memory.c:1740 crash-utility#3 0x0000555555769e1f in raw_stack_dump (stackbase=<optimized out>, size=<optimized out>) at memory.c:2194 crash-utility#4 0x00005555557923ff in get_active_set_panic_task () at task.c:8639 crash-utility#5 0x00005555557930d2 in get_dumpfile_panic_task () at task.c:7628 crash-utility#6 0x00005555557a89d3 in panic_search () at task.c:7380 crash-utility#7 get_panic_context () at task.c:6267 crash-utility#8 task_init () at task.c:687 crash-utility#9 0x00005555557305b3 in main_loop () at main.c:787 ... This is due to lack of existence check on module symbol table. Not all mod_mem_type will be existent for a module, e.g. in the following module case: (gdb) p lm->symtable[0] $1 = (struct syment *) 0x4dcbad0 (gdb) p lm->symtable[1] $2 = (struct syment *) 0x4dcbb70 (gdb) p lm->symtable[2] $3 = (struct syment *) 0x4dcbc10 (gdb) p lm->symtable[3] $4 = (struct syment *) 0x0 (gdb) p lm->symtable[4] $5 = (struct syment *) 0x4dcbcb0 (gdb) p lm->symtable[5] $6 = (struct syment *) 0x4dcbd00 (gdb) p lm->symtable[6] $7 = (struct syment *) 0x0 MOD_RO_AFTER_INIT(3) and MOD_INIT_RODATA(6) do not exist, which should be skipped, otherwise the segmentation fault will happen. Fixes: 7750e61 ("Support module memory layout change on Linux 6.4") Closes: crash-utility#176 Reported-by: Naveen Chaudhary <[email protected]> Signed-off-by: Tao Liu <[email protected]>
I am using crash-8.0.4 release (
make target=ARM64) on my x86_64 host to decode kdump generated on ARM64 target. But when I decode that kdump, thecrashitself crashes.The text was updated successfully, but these errors were encountered: