Hi Kazu, On Thu, Jan 23, 2025 at 3:05 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; wrote: > > 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 > ... > Thanks for reporting the issue, I can reproduce it on my machine. I will look into this and fix. Thanks, Tao Liu > 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