On Mon, Nov 3, 2025 at 11:57 AM Tao Liu <[email protected]> wrote: > On Mon, Nov 3, 2025 at 2:58 PM lijiang <[email protected]> wrote: > > > > On Fri, Oct 31, 2025 at 5:31 AM Tao Liu <[email protected]> wrote: > >> > >> Hi lianbo, > >> > >> On Tue, Oct 28, 2025 at 9:57 PM Lianbo Jiang <[email protected]> > wrote: > >> > > >> > Recently we have observed some failures as below: > >> > > >> > crash> set 2276866 > >> > set: invalid kernel virtual address: 0 type: "stack contents" > >> > set: read of stack at 0 failed > >> > > >> > crash> ps 2276866 > >> > PID PPID CPU TASK ST %MEM VSZ > RSS COMM > >> > 2276866 2276750 47 ff3a19fbd3c80000 ZO 0.0 0 > 0 sh > >> > > >> > This is a regression issue that introduced by adding gdb stack unwind > >> > support. When attempting to read from the stack, firstly, need to > check > >> > if the stack exists, otherwise it may fail in some corner cases. E.g: > >> > there are some zombie processes(ZO) and the stack does not exist. > >> > Furthermore this may also break the switching thread in gdb. > >> > > >> > With the patch: > >> > crash> set 2276866 > >> > PID: 2276866 > >> > COMMAND: "sh" > >> > TASK: ff3a19fbd3c80000 [THREAD_INFO: ff3a19fbd3c80000] > >> > CPU: 47 > >> > STATE: EXIT_DEAD|EXIT_ZOMBIE > >> > > >> > Reported-by: Buland Kumar Singh <[email protected]> > >> > Signed-off-by: Lianbo Jiang <[email protected]> > >> > --- > >> > arm64.c | 2 ++ > >> > ppc64.c | 2 ++ > >> > x86_64.c | 2 ++ > >> > 3 files changed, 6 insertions(+) > >> > > >> > diff --git a/arm64.c b/arm64.c > >> > index 354d17ab6a19..17235950bb60 100644 > >> > --- a/arm64.c > >> > +++ b/arm64.c > >> > @@ -234,6 +234,8 @@ arm64_get_current_task_reg(int regno, const char > *name, > >> > > >> > BZERO(&bt_setup, sizeof(struct bt_info)); > >> > clone_bt_info(&bt_setup, &bt_info, tc); > >> > + if (bt_info.stackbase == 0) > >> > + return FALSE; > >> > fill_stackbuf(&bt_info); > >> > > >> > get_dumpfile_regs(&bt_info, &sp, &ip); > >> > diff --git a/ppc64.c b/ppc64.c > >> > index d1a506773c93..9c5c0a460c7a 100644 > >> > --- a/ppc64.c > >> > +++ b/ppc64.c > >> > @@ -2606,6 +2606,8 @@ ppc64_get_current_task_reg(int regno, const > char *name, int size, > >> > > >> > BZERO(&bt_setup, sizeof(struct bt_info)); > >> > clone_bt_info(&bt_setup, &bt_info, tc); > >> > + if (bt_info.stackbase == 0) > >> > + return FALSE; > >> > fill_stackbuf(&bt_info); > >> > > >> > // reusing the get_dumpfile_regs function to get pt regs > structure > >> > diff --git a/x86_64.c b/x86_64.c > >> > index d7da536d20d8..b2cddbf8ba3d 100644 > >> > --- a/x86_64.c > >> > +++ b/x86_64.c > >> > @@ -9383,6 +9383,8 @@ x86_64_get_current_task_reg(int regno, const > char *name, > >> > > >> > BZERO(&bt_setup, sizeof(struct bt_info)); > >> > clone_bt_info(&bt_setup, &bt_info, tc); > >> > + if (bt_info.stackbase == 0) > >> > + return FALSE; > >> > >> The fix makes sense to me, however, exit directly will make the > >> register cache unrefreshed. That is, with the return "FALSE", "set > >> 2276866" will succeed in task switching, but the register cache is > >> still the old one, so "gdb bt" still outputs the previous stackstrace > >> which is not 2276866's stack. I suggest adding a warning telling users > > > > > > Actually, I haven't seen the case you mentioned, and it works as > expected: > > > > Without the patch: > > crash> set 2276866 > > set: invalid kernel virtual address: 0 type: "stack contents" > > set: read of stack at 0 failed > > > > crash> bt > > PID: 2276866 TASK: ff3a19fbd3c80000 CPU: 47 COMMAND: "sh" > > (no stack) > > > > crash> gdb bt > > #0 crash_setup_regs (oldregs=0x0, newregs=0xff43e468633c7d38) at > ./arch/x86/include/asm/processor.h:58 > > #1 __crash_kexec (regs=regs@entry=0x0) at kernel/kexec_core.c:952 > > #2 0xffffffff86cf976f in panic (fmt=fmt@entry=0xffffffff87f69f99 > "sysrq triggered crash\n") at kernel/panic.c:230 > > #3 0xffffffff87210201 in sysrq_handle_crash (key=<optimized out>) at > drivers/tty/sysrq.c:142 > > #4 0xffffffff87210b24 in __handle_sysrq (key=99, check_mask=<optimized > out>) at drivers/tty/sysrq.c:559 > > #5 0xffffffff872109cb in write_sysrq_trigger (file=<optimized out>, > buf=<optimized out>, count=2, ppos=<optimized out>) at > drivers/tty/sysrq.c:1106 > > #6 0xffffffff86ff5fc9 in proc_reg_write (file=<optimized out>, > buf=<optimized out>, count=<optimized out>, ppos=<optimized out>) at > fs/proc/inode.c:241 > > #7 0xffffffff86f6e845 in vfs_write (pos=0xff43e468633c7f08, count=2, > buf=0x7ffc5b412780 <error: Cannot access memory at address 0x7ffc5b412780>, > file=0xff3a19e92ee37b00) at fs/read_write.c:549 > > #8 vfs_write (file=0xff3a19e92ee37b00, buf=0x7ffc5b412780 <error: > Cannot access memory at address 0x7ffc5b412780>, count=<optimized out>, > pos=0xff43e468633c7f08) at fs/read_write.c:533 > > #9 0xffffffff86f6eacf in ksys_write (fd=<optimized out>, > buf=0x7ffc5b412780 <error: Cannot access memory at address 0x7ffc5b412780>, > count=2) at fs/read_write.c:598 > > #10 0xffffffff86c03cab in do_syscall_64 (nr=1, regs=0xff43e468633c7f58) > at arch/x86/entry/common.c:303 > > #11 0xffffffff8780012e in entry_SYSCALL_64 () at > arch/x86/entry/entry_64.S:147 > > crash> > > > > The above case breaks the switching thread in gdb, just like the patch > log I mentioned. > > > > With the patch: > > crash> set 2276866 > > PID: 2276866 > > COMMAND: "sh" > > TASK: ff3a19fbd3c80000 [THREAD_INFO: ff3a19fbd3c80000] > > CPU: 47 > > STATE: EXIT_DEAD|EXIT_ZOMBIE > > > > crash> bt > > PID: 2276866 TASK: ff3a19fbd3c80000 CPU: 47 COMMAND: "sh" > > (no stack) > > > > crash> gdb bt > > crash> > > > > That is expected behavior, and I did not see the case that you pointed > out. > > > > > >> that gdb related commands such as 'bt', 'frame', 'up', 'down', 'info > >> locals' are not workable, like: > > > > > > Have you reproduced the case that the register cache is unrefreshed? > > Right, I re-test the patch and it work as expected, sorry for the > confusion. For the patch, ack. > > No worries. Thanks for the review, Tao.
Lianbo Thanks, > Tao Liu > > > > > Thanks > > Lianbo > > > >> > >> Warning: registers unable to refresh, the outputs of the following gdb > >> related commands are not reliable: 'bt', 'frame', 'up', 'down', 'info > >> locals'. > >> > >> What do you think? > >> > >> Thanks, > >> Tao Liu > >> > >> > >> > >> > fill_stackbuf(&bt_info); > >> > > >> > // reusing the get_dumpfile_regs function to get pt regs > structure > >> > -- > >> > 2.50.1 > >
-- Crash-utility mailing list -- [email protected] To unsubscribe send an email to [email protected] https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
