sched/group: prevent mm_free() of static g_kthread_group

[mzanders]

Summary

When building for small systems with CONFIG_DEFAULT_SMALL=y, this implies CONFIG_DISABLE_PTHREAD and thus HAVE_GROUP_MEMBERS is undefined. When the AppBringUp task finishes, it will in this case try to free g_kthread_group which is obviously not possible.

Add a guard with a new flag "GROUP_FLAG_STATIC" which indicates the memory allocation type. Before freeing, check for this flag.

Impact

Builds with CONFIG_DEFAULT_SMALL and CONFIG_DISABLE_PTHREAD are working again.

Testing

Debug summary

Building for olimexino-stm32:nsh (STM32F103RB).
With CONFIG_DEFAULT_SMALL in the defconfig, the target is booting with following stackdump:

Current Version: NuttX  12.12.0 acd69cfafb Mar  9 2026 13:40:14 arm
Assertion failed panic: at file: :0 task: AppBringUp process: Kernel 0x8001065
R0: 200007e4 R1: 00000000 R2: 00000000  R3: 200007e4
R4: 20000ce0 R5: 200007e8 R6: 200007e4  FP: 00000000
R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
IP: 00000000 SP: 200016f8 LR: 08004175  PC: 080041b6
xPSR: 01000000 BASEPRI: 00000080 CONTROL: 00000000
EXC_RETURN: fffffff9
User Stack:
  base: 0x20000f68
  size: 00002000
    sp: 0x200016f8
0x200016d8: 200007e4 00000000 00000000 200007e4 00000000 08004175 080041b6 01000000
0x200016f8: 200008d4 200007e8 20000eb0 00000000 00000000 08001f6d 00000000 00000000
0x20001718: 20000eb0 08001c0b 00000000 08001bc9 00000000 00000000 00000000 00000000
0x20001738: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
   PID GROUP PRI POLICY   TYPE    NPX STATE   EVENT      SIGMASK          STACKBASE  STACKSIZE   COMMAND
      0     0   0 FIFO     Kthread -   Ready              0000000000000000 0x200008f8      1000   Idle_Task
      1     0 240 FIFO     Kthread P   Running            0000000000000000 0x20000f68      2000   AppBringUp
      2     2 100 FIFO     Task    -   Ready              0000000000000000 0x200018c0      2000   nsh_main

Lookup up PC 0x080041b6 in the system map reveals:

..
 .text.mm_delayfree
                0x08004140      0x11a /home/maarten/work/nuttx/nuttx/staging/libmm.a(mm_free.o)
                0x08004140                mm_delayfree
 .text.mm_free  0x0800425a        0xa /home/maarten/work/nuttx/nuttx/staging/libmm.a(mm_free.o)
                0x0800425a 
..

Setting a breakpoint with GDB on mm_delayfree() reveals more context. This is the only time the breakpoint is hit; it fails after this.

Breakpoint 1.1, mm_delayfree (heap=0x20000ce0, mem=0x200007e8 <g_kthread_group>, delay=false)
    at mm_heap/mm_free.c:92
92	  if (mm_lock(heap) < 0)
(gdb) bt
#0  mm_delayfree (heap=0x20000ce0, mem=0x200007e8 <g_kthread_group>, delay=false) at mm_heap/mm_free.c:92
#1  0x08001f6c in group_release (group=0x200007e8 <g_kthread_group>) at group/group_leave.c:134
#2  group_leave (tcb=0x20000eb0) at group/group_leave.c:190
#3  0x080021fe in nxtask_exithook (tcb=<optimized out>, status=status@entry=0) at task/task_exithook.c:454
#4  0x08001c0a in _exit (status=0) at task/exit.c:97
#5  0x08001bc8 in nxtask_start () at task/task_start.c:112
#6  0x00000000 in ?? ()
(gdb)

Note the g_kthread_group in the arguments. It is obvious that a static struct should not be freed.

Fix validation

After patching, the board boots normally:

NuttShell (NSH) NuttX-12.12.0
nsh> help
help usage:  help [-v] [<cmd>]

    ?       help    

Builtin Apps:
    nsh    sh     
nsh> 

[mzanders]

I'm not an expert on this matter. I simply added a guard around the failing call. It might be better in terms of group management to handle the case at an earlier stage, I'm open for suggestions if this approach can be improved.

[cederom]

Thank you @mzanders good catch! :-)

CI failed, restarted, GH has some issues recently :-)

[linguini1]

Great test info and explanation!

[cederom]

@mzanders could you please rebase on top of current master there were some esp32 fixes merged recently hope that fixes build issues :-)

https://nuttx.apache.org/docs/latest/contributing/making-changes.html#how-to-include-the-suggestions-on-your-pull-request

[mzanders]

@mzanders could you please rebase on top of current master there were some esp32 fixes merged recently hope that fixes build issues :-)

https://nuttx.apache.org/docs/latest/contributing/making-changes.html#how-to-include-the-suggestions-on-your-pull-request

I was suspecting something like that... Just pushed a rebased version!

[xiaoxiang781216]

@mzanders you need fix:

====================================================================================
Configuration/Tool: esp32-devkitc/softap
2026-03-11 09:41:05
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Building NuttX...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

  3  340k    3 13160    0     0  46096      0  0:00:07 --:--:--  0:00:07 46096
100  340k  100  340k    0     0  1106k      0 --:--:-- --:--:-- --:--:-- 15.2M
Traceback (most recent call last):
  File "/usr/local/bin/esptool.py", line 37, in <module>
    esptool._main()
  File "/usr/local/lib/python3.10/dist-packages/esptool/__init__.py", line 1170, in _main
    main()
  File "/usr/local/lib/python3.10/dist-packages/esptool/__init__.py", line 983, in main
    operation_func(args)
  File "/usr/local/lib/python3.10/dist-packages/esptool/cmds.py", line 1097, in elf2image
    image.save(args.output)
  File "/usr/local/lib/python3.10/dist-packages/esptool/bin_image.py", line 778, in save
    assert (f.tell() + 8 + self.ROM_LOADER.BOOTLOADER_FLASH_OFFSET) % (
AssertionError
make: *** [tools/Unix.mk:572: nuttx] Error 1
make: Target 'all' not remade because of errors.
  [1/1] Normalize esp32-devkitc/softap

@tmedicci could you help?

[mzanders]

@xiaoxiang781216
@mzanders you need fix:
...

I tried building that target (esp32-devkitc/softap) locally and it works. I'm not sure what to do here... The failing assertion has to do with alignment of linked segments, I really don't see any connection with my change.

[tmedicci]

@xiaoxiang781216
@mzanders you need fix:
...

I tried building that target (esp32-devkitc/softap) locally and it works. I'm not sure what to do here... The failing assertion has to do with alignment of linked segments, I really don't see any connection with my change.

Hi, I'm sorry for the late response. Can you please check which esptool version is used locally and which version is used on CI?

Probably just updating would solve the issue.

[simbit18]

Hi @tmedicci, we use this version

nuttx/tools/ci/docker/linux/Dockerfile

Line 409 in 4aca170

RUN pip3 install esptool==4.8.dev4

[mzanders]

@tmedicci
Hi, I'm sorry for the late response. Can you please check which esptool version is used locally and which version is used on CI?

Probably just updating would solve the issue.

The one that comes with my ubuntu 24.04 seems to be 5.2.0.

[simbit18]

@tmedicci, is it necessary to update esptool on the Nuttx docker image?
If so, which version?

[eren-terzioglu]

@tmedicci, is it necessary to update esptool on the Nuttx docker image? If so, which version?

Hi,
esptool v5.2.0 should be fine.

[cederom]

The problem here is esptool changed CLI interface (i.e. flash_id -> flash-id) that breaks compatibility with all older v4 environments and all build commands will have to be updated.

Why such change? No clue :-(

[eren-terzioglu]

The problem here is esptool changed CLI interface (i.e. flash_id -> flash-id) that breaks compatibility with all older v4 environments and all build commands will have to be updated.

Why such change? No clue :-(

It just gives warning and works for now but later old commands will be dropped. For updates of those commands, there is an open PR #16723.

[cederom]

Maybe for build parts we should use local tools fork to avoid this "deprecation" situations? This is exactly why NuttX avoids external SDKs :-(

[cederom]

Anyway, this change does not seem to be related, @mzanders could you please try rebase again on top of current master?

[mzanders]

@cederom Anyway, this change does not seem to be related, @mzanders could you please try rebase again on top of current master?

Done. Although I don't see any change that would alter the behavior.
To me it feels that something is just setup incorrect in the ESP build config. As if we're causing a misalignment due to the addition of a few instructions. Since it's still working on other PR's, we must be hitting a corner case here that should be fixable without updating the tool.
I'm planning to look at it in more detail but didn't have time yet.