Yeah, it's usually the stack, but does anyone know why it needs to be enlarged now? Is something using more stack than before?
On Sat, Feb 7, 2026 at 5:28 PM Peter Barada <[email protected]> wrote: > Cranking up CONFIG_INIT_STACKSIZE to 3072 fixes the issue. > > I tried enabling STACK_COLORATION, STACK_USAGE, and ARMV7M_STACKTRACE > while leaving INIT_STACKSIZE at 2048 to hopefully and debug using > STM32CubeIDE when I try "time ls" the GDB session is lost (which seems > strange). > > If I then enable ARMV7M_STACKCHECK_BREAKPOINT GDB stops when it detects > the stack overflow can get a call stack to understand why but can't > continue(to show dump). > > Finally after enabling ARCH_STACKDUMP, ARMV7M_STACKCHECK, > SCHED_BACKTRACE, STACK_COLORATION, STACK_USAGE, disable > STACKCHECK_BREAKPOINT, and enable/set ARCH_INTERRUPTSTACK=2048, and > ARCH_STACKDUMP_MAX_LENGTH=1024, I get a full dump when it detects stack > overflow. > > Thanks for the help! > > > On 2/7/26 03:25, raiden00pl wrote: > > hi, this is a 100% stack issue. Increase all stack sizes to at least > 4092. > > Another option is to enable full optimisation with > CONFIG_DEBUG_FULLOPT=y, > > should also help. > > > > quick tip: about 80% of crashes in NuttX are stack issues, the first > thing > > you > > always do when such crashes occur is to increase all stack sizes :) > > > > sob., 7 lut 2026 o 04:02 Matteo Golin <[email protected]> > napisał(a): > > > >> I am not familiar enough, but there should be an option for stack > canaries. > >> I haven't had much luck with that configuration, and I imagine that your > >> DEBUGASSERT will trigger before stack smashing is detected. > >> > >> Matteo > >> > >> On Fri, Feb 6, 2026, 8:45 PM Peter Barada <[email protected]> > wrote: > >> > >>> Haven't tried yet(personally feel should know _why_ it happens) - is > >> there > >>> a config for compiling in stack checking on function entry? > >>> On 2/6/26 20:22, Matteo Golin wrote: > >>> > >>> Hmmm, if the problem goes that far back it may not be worth triaging > that > >>> way. Things have probably diverged so much since then. No luck with the > >>> stack increase? > >>> > >>> Matteo > >>> > >>> On Fri, Feb 6, 2026, 8:18 PM Peter Barada <[email protected]> > >> wrote: > >>>> Matteo, > >>>> > >>>> I'm walking back release points and have had to change board > >>>> configuration names(to nucleo-h743zi), rename nuttx-apps to appa, and > >> still > >>>> seeing the fault in release/11.0 branch. > >>>> > >>>> I'm trying to go back further but wondering if I'll find a bisect > start > >>>> point... > >>>> On 2/6/26 17:05, Matteo Golin wrote: > >>>> > >>>> Hi Peter, > >>>> > >>>> My approach is kind of a headache since bisecting over an area where > >> apps > >>>> and NuttX are not always in sync is a major limitation of the split > >> repo. > >>>> My approach is usually: > >>>> > >>>> - Start the bisect in kernel > >>>> - Check the commit date of the current HEAD > >>>> - Check out to a commit of the same/similar date in apps > >>>> - Build > >>>> - Mentally note if this commit was good or bad based on the results of > >>>> running the image > >>>> - make distclean (avoids artifacts carrying over between bisections > and > >>>> breaking everything) > >>>> - Mark commit good or bad with git bisect > >>>> > >>>> Then basically repeat this until bisecting is finished. It sucks and I > >>>> did suggest a script in /tools/ to try and automate most of this, but > I > >>>> never got around to writing it. > >>>> > >>>> I would suggest you start by checking for the issue on a stable > release > >>>> (i.e. 12.12.0) to see if that's a good commit you can start from. > >> Usually > >>>> those releases have a higher degree of testing because everyone who > >> voted > >>>> for the release ran some images on their hardware. > >>>> > >>>> That's honestly a lot of work but you never know if it'll end up being > >>>> faster than trying to triage with logs! > >>>> > >>>> Matteo > >>>> > >>>> On Fri, Feb 6, 2026, 4:50 PM Nathan Hartman <[email protected] > > > >>>> wrote: > >>>> > >>>>> First place I would look: is the stack overflowing? (You could try > >>>>> enabling some of the stack debugging features.) > >>>>> > >>>>> On Fri, Feb 6, 2026 at 4:34 PM Peter Barada <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> Matteo, > >>>>>> > >>>>>> I don't know if this was working before but if you can suggest a > good > >>>>>> starting point I can cycle through git bisect to narrow down to the > >>>>>> failing commit. What's the best approach to using git bisect across > >>>>>> multiple repos (since changes in nuttx may have necessary changes in > >>>>>> nuttx-apps and need to keep them in sync at each build point)? > >>>>>> > >>>>>> As an aside, I also I have a nucleo-f446re board 'time ls' works > fine > >>>>>> there. > >>>>>> > >>>>>> Further, does anyone have GDB scripts that make it easier to > decipher > >>>>>> Nuttx structures from memory (e.g. dump task/semaphore lists, etc)? > >>>>>> I've > >>>>>> started cobbling snippets but figure I'd ask before reinventing the > >>>>>> wheel. > >>>>>> > >>>>>> > >>>>>> On 2/6/26 16:12, Matteo Golin wrote: > >>>>>>> Hi Peter, > >>>>>>> > >>>>>>> If you happen to know that this was working before on an older > NuttX > >>>>>>> version, you could use git bisect to narrow down the breaking > >> commit. > >>>>>>> Then the issue might be clearer. > >>>>>>> > >>>>>>> Best, > >>>>>>> Matteo > >>>>>>> > >>>>>>> On Fri, Feb 6, 2026, 4:09 PM Peter Barada <[email protected]> > >>>>>> wrote: > >>>>>>> I have a STM32 Nucleo-h753zi board - and configured a build > for > >>>>>>> nucleo-743zi2:nsh (which is closest board/chip; the > stm32h753zi > >>>>>> is > >>>>>>> same > >>>>>>> as stm32h743zi but h753zi includes crypto acceleration > >> hardware). > >>>>>>> Build works, but if I boot and try 'time ls' nuttx faults: > >>>>>>> > >>>>>>> nsh> uname -a > >>>>>>> NuttX 0.0.0 9ecfff0833 Feb 6 2026 15:45:28 arm nucleo-h743zi2 > >>>>>>> nsh> time ls > >>>>>>> /: > >>>>>>> dev/ > >>>>>>> > >>>>>>> 0.00dump_assert_info: Current Version: NuttX 0.0.0 9ecfff0833 > >>>>>>> Feb 6 2026 15:45:28 arm > >>>>>>> dump_assert_info: Assertion failed panic: at file: :0 task: > >>>>>>> <noname> process: <noname> 0x800c9fd > >>>>>>> up_dump_register: R0: 0801e624 R1: 0000000a R2: 00000050 R3: > >>>>>> 0000000a > >>>>>>> up_dump_register: R4: 00000001 R5: 240000e4 R6: 00000000 FP: > >>>>>> 00000000 > >>>>>>> up_dump_register: R8: 00000000 SB: 00000000 SL: 00000000 R11: > >>>>>> 00000000 > >>>>>>> up_dump_register: IP: 00000000 SP: 38000c08 LR: 080059db PC: > >>>>>> 08005984 > >>>>>>> up_dump_register: xPSR: 41000000 BASEPRI: 00000000 CONTROL: > >>>>>> 00000000 > >>>>>>> up_dump_register: EXC_RETURN: ffffffe9 > >>>>>>> dump_stackinfo: User Stack: > >>>>>>> dump_stackinfo: base: 0x38000518 > >>>>>>> dump_stackinfo: size: 00002000 > >>>>>>> dump_stackinfo: sp: 0x38000c08 > >>>>>>> stack_dump: 0x38000be8: 00000000 00000000 00000000 00000000 > >>>>>>> 00000000 00000000 00000000 00000000 > >>>>>>> stack_dump: 0x38000c08: 0000000a 0801e624 0801e624 38000200 > >>>>>>> 38000fac 00000000 0801e624 080172c1 > >>>>>>> stack_dump: 0x38000c28: 00000000 0801e624 38000200 38000158 > >>>>>>> 00000000 00000000 38000fac 0800caa1 > >>>>>>> stack_dump: 0x38000c48: 00000000 0800cc77 0801e624 000002fc > >>>>>>> 38000500 00000001 00000001 38000cf0 > >>>>>>> stack_dump: 0x38000c68: 38000cf0 00000008 38000200 00000000 > >>>>>>> 00000000 0800ca79 38000500 00000001 > >>>>>>> stack_dump: 0x38000c88: 00000064 38000cf0 00000064 0800ca33 > >>>>>>> 38000500 00000001 00000064 00000000 > >>>>>>> stack_dump: 0x38000ca8: 00000000 08009325 00000000 38000500 > >>>>>>> 00000001 0800c9fd 00000000 080052f1 > >>>>>>> stack_dump: 0x38000cc8: 00000000 38000500 00000000 38000158 > >>>>>>> 00000001 00000001 00000000 00000000 > >>>>>>> stack_dump: 0x38000ce8: 00000000 00000000 00000000 00000000 > >>>>>>> 00000000 00000000 00000000 00000000 > >>>>>>> dump_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT > >>>>>>> SIGMASK STACKBASE STACKSIZE COMMAND > >>>>>>> dump_task: 0 0 0 FIFO Kthread - Ready > >>>>>>> 0000000000000000 0x240018b0 1000 <noname> > >>>>>>> dump_task: 1 1 100 RR Task - Running > >>>>>>> 0000000000000000 0x38000518 2000 <noname> ��]���& > >>>>>>> > >>>>>>> Wondering if anyone has run across this before? Backtrace > >> shows: > >>>>>>> Program received signal SIGTRAP, Trace/breakpoint trap. > >>>>>>> exception_common () at armv7-m/arm_exception.S:127 > >>>>>>> 127 mrs r0, ipsr /* > >> R0=exception > >>>>>>> number */ > >>>>>>> where > >>>>>>> #0 exception_common () at armv7-m/arm_exception.S:127 > >>>>>>> #1 <signal handler called> > >>>>>>> #2 0x08005984 in env_cmpname (pszname=0x801e624 "PS1", > >>>>>>> peqname=0xa <error: Cannot access memory at address 0xa>) > >>>>>>> at environ/env_findvar.c:50 > >>>>>>> #3 0x080059da in env_findvar (group=0x38000200, > pname=0x801e624 > >>>>>>> "PS1") > >>>>>>> at environ/env_findvar.c:105 > >>>>>>> #4 0x080172c0 in getenv (name=0x801e624 "PS1") at > >>>>>>> environ/env_getenv.c:89 > >>>>>>> #5 0x0800caa0 in nsh_update_prompt () at nsh_prompt.c:77 > >>>>>>> #6 0x0800cc76 in nsh_session (pstate=0x38000cf0, login=1, > >> argc=1, > >>>>>>> argv=0x38000500) at nsh_session.c:249 > >>>>>>> #7 0x0800ca78 in nsh_consolemain (argc=1, argv=0x38000500) > >>>>>>> at nsh_consolemain.c:77 > >>>>>>> #8 0x0800ca32 in nsh_main (argc=1, argv=0x38000500) at nsh_ > >>>>>> main.c:76 > >>>>>>> #9 0x08009324 in nxtask_startup (entrypt=0x800c9fd > <nsh_main>, > >>>>>>> argc=1, > >>>>>>> argv=0x38000500) at sched/task_startup.c:72 > >>>>>>> #10 0x080052f0 in nxtask_start () at task/task_start.c:104 > >>>>>>> #11 0x00000000 in ?? () > >>>>>>> > >>>>>>> Scratching the surface shows that env_findvar() is called with > >>>>>> group > >>>>>>> pointer of 0x38000200, group->tg_envp is 0x380004b8, both > which > >>>>>> are > >>>>>>> reasonable. But *group->tg_envp is 0xA. Further if I "watch > >>>>>>> *(int*)0x380004b8" in GDB, I see it is getting overwritten by > >>>>>>> up_serialout() invoked from stm32_serial.c::up_send. > >>>>>>> > >>>>>>> Any suggestions on how I can best track this down further? > >>>>>>> > >>>>>>> Thanks in advance! > >>>>>>> > >>>>>>> -- > >>>>>>> Peter Barada > >>>>>>> [email protected] > >>>>>>> > >>>>>> -- > >>>>>> Peter Barada > >>>>>> [email protected] > >>>>>> > >>>>> -- > >>>> Peter [email protected] > >>>> > >>>> -- > >>> Peter [email protected] > >>> > >>> > -- > Peter Barada > [email protected] > >
