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
