[Crash-utility] bug report: "bt -S" option causes a segfault on x86_64
Hi Tao, Lianbo,
Using the latest crash (0f39e33), "bt -S" option always causes a segfault.
crash> bt
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
#0 [ffffb39fc107fc00] machine_kexec at ffffffff9b26f107
#1 [ffffb39fc107fc58] __crash_kexec at ffffffff9b3e4b9a
#2 [ffffb39fc107fd18] panic at ffffffff9bda56e6
...
crash> bt -S ffffb39fc107fc00
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
Segmentation fault
crash-8.0.5 doesn't cause this with the same command.
crash> bt -S ffffb39fc107fc00
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
#0 [ffffb39fc107fc58] __crash_kexec at ffffffff9b3e4b9a
#1 [ffffb39fc107fd18] panic at ffffffff9bda56e6
#2 [ffffb39fc107fd98] sysrq_handle_crash at ffffffff9b93ec16
...
Looking the core and source,
Program terminated with signal 11, Segmentation fault.
#0 x86_64_get_stack_frame (bt=0x7ffe84940e30, pcp=0x7ffe84940600, spp=0x0) at
x86_64.c:5013
5013 ulong spp_save = *spp;
(gdb) bt
#0 x86_64_get_stack_frame (bt=0x7ffe84940e30, pcp=0x7ffe84940600, spp=0x0) at
x86_64.c:5013
#1 0x000000000057900a in back_trace (bt=bt@entry=0x7ffe84940e30) at kernel.c:3094
#2 0x000000000058472b in cmd_bt () at kernel.c:2781
#3 0x00000000004fe1ac in exec_command () at main.c:893
#4 0x00000000004fe43a in main_loop () at main.c:840
#5 0x0000000000810b4d in captured_main (data=data@entry=0x7ffe84941610) at main.c:1284
#6 gdb_main (args=args@entry=0x7ffe84941630) at main.c:1313
#7 0x0000000000810c05 in gdb_main_entry (argc=<optimized out>,
argv=argv@entry=0x7ffe84941798) at main.c:1338
#8 0x000000000058fff9 in gdb_main_loop (argc=<optimized out>, argc@entry=3,
argv=argv@entry=0x7ffe84941798) at gdb_interface.c:81
#9 0x00000000004f6c65 in main (argc=3, argv=0x7ffe84941798) at main.c:721
3013 void
3014 back_trace(struct bt_info *bt)
3015 {
...
3091 eip = bt->hp->eip;
3092 esp = bt->hp->esp;
3093
3094 machdep->get_stack_frame(bt, eip ? NULL : &eip,
3095 esp ? NULL : &esp);
5011 static void
5012 x86_64_get_stack_frame(struct bt_info *bt, ulong *pcp, ulong *spp)
5013 {
5014 struct user_regs_bitmap_struct *ur_bitmap;
5015 ulong pcp_save = *pcp;
5016 ulong spp_save = *spp; <<--
5017 ulong sp;
So it may be fixed like "spp_save = spp ? *spp : 0" here (also pcp for bt -I),
but spp/pcp are passed to x86_64_get_dumpfile_stack_flame() too, and it looks
like this function doesn't check whether they are NULL.
*pcp = pcp_save;
*spp = spp_save;
return x86_64_get_dumpfile_stack_frame(bt, pcp, spp);
Do you have any idea about how to fix the issue?
(Is the BT_DUMPFILE_SEARCH block not executed with them being NULL? because
they were not checked also before 89ff1e4573...)
Thanks,
Kazu