Hi Kazu, Could you please try the patch [1] to check if it works for you? [1]: https://www.mail-archive.com/devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx/msg01327.html Thanks, Tao Liu On Thu, Jan 23, 2025 at 6:09 PM Tao Liu <ltao@xxxxxxxxxx> wrote: > > Hi Kazu, > > On Thu, Jan 23, 2025 at 3:05 PM HAGIO KAZUHITO(萩尾 一仁) > <k-hagio-ab@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx > > https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ > > Contribution Guidelines: https://github.com/crash-utility/crash/wiki -- Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
