[Crash-utility] Re: 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 -- Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki