hitHuang opened a new pull request, #19487:
URL: https://github.com/apache/nuttx/pull/19487
## Summary
When an exception occurs while already inside interrupt handling, and the
task being reported has no kernel stack (e.g. idle), `dump_stacks()` can still
attempt to dump the "Kernel" stack section for it, reading raw memory starting
at address 0. That triggers a second exception in the middle of dumping the
panic, truncating the output before the crash scene (user stack, backtrace,
task list) can be captured. The fix skips the Kernel stack dump when the task
has no kernel stack to begin with.
## Impact
Only `CONFIG_ARCH_KERNEL_STACK` builds, and only during a panic reported for
a task with no kernel stack.
## Testing
Tested on QEMU `rv-virt:knsh` and `rv-virt:knsh64` by writing to a NULL
pointer from inside an interrupt handler, so the fault is reported against the
idle task.
Before fix: the dump itself faults while trying to print the Kernel stack,
so a second exception is raised mid-backtrace and the log is cut short. (The
timestamps in the log are a separate, still-under-investigation issue — ignore
them here.)
```
ABC
NuttShell (NSH) NuttX-13.0.0
nsh> [2598455214080000.001000] riscv_exception: EXCEPTION: Store/AMO access
fault. MCAUSE: 00000007, EPC: 8020cc90, MTVAL: 00000000
[2598455214080000.001000] riscv_fault_handler: PANIC!!! Exception = 00000007
[2598455214080000.001000] dump_assert_info: Current Version: NuttX 13.0.0
522ae4cb3f-dirty Jul 20 2026 10:41:35 risc-v
[2598455214080000.001000] dump_assert_info: Assertion failed panic: at file:
common/riscv_exception.c:135 task: Idle_Task process: Kernel 0x80201bf0
[2598455214080000.001000] up_dump_register: EPC: 8020cc90
[2598455214080000.001000] up_dump_register: A0: 00000015 A1: 80608564 A2:
80600138 A3: 00000002
[2598455214080000.001000] up_dump_register: A4: 00000002 A5: 80608000 A6:
00000002 A7: 00000000
[2598455214080000.001000] up_dump_register: T0: 80606800 T1: 80606000 T2:
00001000 T3: 8001e8a1
[2598455214080000.001000] up_dump_register: T4: 80045f30 T5: 00000088 T6:
00000000
[2598455214080000.001000] up_dump_register: S0: 806067a8 S1: 80608000 S2:
00000015 S3: 80608000
[2598455214080000.001000] up_dump_register: S4: 80606838 S5: 00000000 S6:
00000001 S7: 0000007f
[2598455214080000.001000] up_dump_register: S8: 00002000 S9: 80042300 S10:
00000000 S11: 00000000
[2598455214080000.001000] up_dump_register: SP: 80606798 FP: 806067a8 TP:
80606838 RA: 80201fec
[2598455214080000.001000] dump_stackinfo: IRQ Stack:
[2598455214080000.001000] dump_stackinfo: base: 0x80606000
[2598455214080000.001000] dump_stackinfo: size: 00002048
[2598455214080000.001000] dump_stackinfo: sp: 0x80606798
[2598455214080000.001000] stack_dump: 0x80606778: 00000001 00000000 80606838
80608000 00000015 80608000 806067a8 8020cc78
[2598455214080000.001000] stack_dump: 0x80606798: 00000000 00000000 806067b8
80201fec 00000000 00000000 806067e8 8020162a
[2598455214080000.001000] stack_dump: 0x806067b8: 00000000 00000000 00000000
80608564 00000000 80608000 80606838 806086f0
[2598455214080000.001000] stack_dump: 0x806067d8: 80000005 8020cf92 806067f8
80201262 80000005 8020cf92 80606800 802001e8
[2598455214080000.001000] stack_dump: 0x806067f8: 80608700 8020cf92 00000000
00000000 00000000 00000000 00000000 00000000
[2598455214080000.001000] sp_out_of_range: ERROR: Stack pointer 80606798 is
not within the stack
[2598455214080000.001000] dump_stackinfo: Kernel Stack:
[2598455214080000.001000] dump_stackinfo: base: 0
[2598455214080000.001000] dump_stackinfo: size: 00003072
[ 0.605000] riscv_exception: EXCEPTION: Load access fault. MCAUSE:
00000005, EPC: 80216dec, MTVAL: 00000000
[ 0.605000] riscv_fault_handler: PANIC!!! Exception = 00000005
```
After fix: the Kernel stack dump is skipped and the rest of the panic log,
including the User stack, backtrace, and task list, prints correctly.
```
ABC
NuttShell (NSH) NuttX-13.0.0
nsh> [1387274436608000.001000] riscv_exception: EXCEPTION: Store/AMO access
fault. MCAUSE: 00000007, EPC: 8020cc90, MTVAL: 00000000
[1387274436608000.001000] riscv_fault_handler: PANIC!!! Exception = 00000007
[1387274436608000.001000] dump_assert_info: Current Version: NuttX 13.0.0
413f061d8f-dirty Jul 20 2026 10:45:32 risc-v
[1387274436608000.001000] dump_assert_info: Assertion failed panic: at file:
common/riscv_exception.c:135 task: Idle_Task process: Kernel 0x80201bf0
[1387274436608000.001000] up_dump_register: EPC: 8020cc90
[1387274436608000.001000] up_dump_register: A0: 00000015 A1: 80608564 A2:
80600138 A3: 00000002
[1387274436608000.001000] up_dump_register: A4: 00000002 A5: 80608000 A6:
00000002 A7: 00000000
[1387274436608000.001000] up_dump_register: T0: 80606800 T1: 80606000 T2:
00001000 T3: 8001e8a1
[1387274436608000.001000] up_dump_register: T4: 80045f30 T5: 00000088 T6:
00000000
[1387274436608000.001000] up_dump_register: S0: 806067a8 S1: 80608000 S2:
00000015 S3: 80608000
[1387274436608000.001000] up_dump_register: S4: 80606838 S5: 00000000 S6:
00000001 S7: 0000007f
[1387274436608000.001000] up_dump_register: S8: 00002000 S9: 80042300 S10:
00000000 S11: 00000000
[1387274436608000.001000] up_dump_register: SP:
80606798 FP: 806067a8 TP: 80606838 RA: 80201fec
[1387274436608000.001000] dump_stackinfo: IRQ Stack:
[1387274436608000.001000] dump_stackinfo: base: 0x80606000
[1387274436608000.001000] dump_stackinfo: size: 00002048
[1387274436608000.001000] dump_stackinfo: sp: 0x80606798
[1387274436608000.001000] stack_dump: 0x80606778: 00000001 00000000 80606838
80608000 00000015 80608000 806067a8 8020cc78
[1387274436608000.001000] stack_dump: 0x80606798: 00000000 00000000 806067b8
80201fec 00000000 00000000 806067e8 8020162a
[1387274436608000.001000] stack_dump: 0x806067b8: 00000000 00000000 00000000
80608564 00000000 80608000 80606838 806086f0
[1387274436608000.001000] stack_dump: 0x806067d8: 80000005 8020cf92 806067f8
80201262 80000005 8020cf92 80606800 802001e8
[1387274436608000.001000] stack_dump: 0x806067f8: 80608700 8020cf92 00000000
00000000 00000000 00000000 00000000 00000000
[1387274436608000.001000] sp_out_of_range: ERROR: Stack pointer 80606798 is
not within the stack
[1387274436608000.001000] dump_stackinfo: User Stack:
[1387274436608000.001000] dump_stackinfo: base: 0x80607b60
[1387274436608000.001000] dump_stackinfo: size: 00003040
[1387274436608000.001000] stack_dump: 0x80607b60: 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
······
[1387274436608000.001000] stack_dump: 0x80608740: 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x80218e48
0x8021c992 0x802172e4 0x8020c860 0x80201fec 0x8020162a 0x80201262 0x802001e8
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x8020cc90
0x80201fec 0x8020162a 0x80201262 0x802001e8 0x8020cf92 0x80608730 0x802011d6
[1387274436608000.001000] sched_dumpstack:
backtrace| 0: 0x8020004a 0x8020cc90 0x80201fec 0x8020162a 0x80201262 0x802001e8
0x8020cf92 0x80608730
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x802011d6
0x8020004a
[1387274436608000.001000] dump_tasks: PID GROUP PRI POLICY TYPE NPX
STATE EVENT SIGMASK STACKBASE STACKSIZE COMMAND
[1387274436608000.001000] dump_tasks: ---- --- --- -------- ------- ---
------- ---------- ---------------- 0x80606000 2048 irq
[1387274436608000.001000] dump_task: 0 0 0 FIFO Kthread -
Running 0000000000000000 0x80607b60 3040 Idle_Task
[1387274436608000.001000] dump_task: 1 0 100 RR Kthread -
Waiting Semaphore 0000000000000000 0x8060a050 1968 lpwork 0x80600010
0x80600060
[1387274436608000.001000] dump_task: 3 3 100 RR Task -
Waiting Semaphore 0000000000000000 0xc0802040 3008 /system/bin/init
[1387274436608000.001000] sched_dumpstack: backtrace| 0:
0x80218e48 0x8021c992 0x80216e74 0x8021880c 0x80217344 0x8020c860 0x80201fec
0x8020162a
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x80201262
0x802001e8 0x8020cc90 0x80201fec 0x8020162a 0x80201262 0x802001e8 0x8020cf92
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x80608730
0x802011d6 0x8020004a 0x8020cc90 0x80201fec 0x8020162a 0x80201262 0x802001e8
[1387274436608000.001000] sched_dumpstack: backtrace| 0: 0x8020cf92
0x80608730 0x802011d6 0x8020004a
[1387274436608000.001000] sched_dumpstack: backtrace| 1: 0x8020cafc
0x80218ffc 0x80208cfc 0x80208d20 0x8020312c 0x80202a94
[1387274436608000.001000] sched_dumpstack: backtrace| 3: 0xc000c348
0xc00027ca 0xc0003ff0 0xc000288a 0xc000264e 0xc0002542 0xc0000b4a 0xc0000b08
```
`tcb->xcp.regs` is overwritten unconditionally on every trap entry with no
save/restore across nested traps, so when a fault happens while already inside
another trap, `dump_stacks()` recovers the innermost trap's context instead of
the original task's — that's why `sp_out_of_range()`/the fallback path gets hit
here at all. That's a separate, deeper issue and out of scope for this PR. Even
if `xcp.regs` were fixed, this guard would still be needed: `force` can also be
set when the initial panic-time sp doesn't fall into any known stack range at
all, independent of nesting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
