ESP32 DevkitC: device crash found when run `ls`

[royfengsss]

Configure nuttx with esp32-devkitc/psram_usrheap
Enable DEBUG_ASSERTIONS and build and flash

After device startup and enter nsh, run ls, crash happeded as below

nsh> ls
/:
_assert: Current Version: NuttX  0.0.0 c9f610f44f-dirty Jun 24 2023 08:47:56 xtensa
_assert: Assertion failed (mem == ((void*)0)) || kmm_heapmember(mem): at file: kmm_heap/kmm_free.c:55 task: nsh_main 0x400d94fc
up_dump_register:    PC: 400e4b15    PS: 00060020
up_dump_register:    A0: 800e1aad    A1: 3f800710    A2: 00000000    A3: 3ffb2640
up_dump_register:    A4: 20000000    A5: 3f800710    A6: 00000000    A7: 3f800848
up_dump_register:    A8: 800d5e2e    A9: 3f8007b0   A10: 00000000   A11: 00000000
up_dump_register:   A12: 00000022   A13: 3f800870   A14: 00000008   A15: 4de28520
up_dump_register:   SAR: 00000000 CAUSE: 00000003 VADDR: 00000008
up_dump_register:  LBEG: 4000c46c  LEND: 4000c477  LCNT: 00000000
dump_stack: User Stack:
dump_stack:   base: 0x3f8003a0
dump_stack:   size: 00001984
dump_stack:     sp: 0x3f800710
stack_dump: 0x3f800700: 3f40100a 00000037 3f40100a 00000037 3f405d75 3f800710 3f40100a 00000037
stack_dump: 0x3f800720: 800d74fd 3f800810 3f40100a 00000037 3ffaf87c 400d94fc 3f800890 00000000
stack_dump: 0x3f800740: 7474754e 3f400058 157e57d8 50000051 800edbed 3f800080 3f800818 3f8007d8
stack_dump: 0x3f800760: 00000002 00000200 00000000 00000001 800e3921 302e3000 3f00302e 3f40470f
stack_dump: 0x3f800780: 00000002 400e3a88 39630000 30313666 66343466 7269642d 4a207974 32206e75
stack_dump: 0x3f8007a0: 30322034 30203332 37343a38 0036353a 800dae24 3f800860 3f800b68 6574780f
stack_dump: 0x3f8007c0: 0061736e 400e3a88 400e3a44 400edbdc 3f800818 00000000 6f720a2f 00000063
stack_dump: 0x3f8007e0: 000007c0 00000000 00000000 3f800e38 3f800710 3f405d75 3ffaf7f8 00000000
stack_dump: 0x3f800800: 800df238 3f800830 3f800e78 00060220 3f400fdf 400dacb4 00000000 3f800e48
stack_dump: 0x3f800820: 800de167 3f800850 00000000 3ffafa80 00000000 00000000 00000063 00000001
stack_dump: 0x3f800840: 800dde45 3f800870 3f800890 3ffb3fb4 3ffb4570 3f800e78 00000000 00000001
stack_dump: 0x3f800860: 800dde58 3f800890 3ffaf7f8 3ffaf990 00000000 3ffaf9a0 3ffb3fb4 00000001
stack_dump: 0x3f800880: 800dde68 3f8008c0 00000003 3f800e4c 00000c01 00000002 3ffb3fb4 3ffafa80
stack_dump: 0x3f8008a0: 3ffaf900 3ffaf900 00000008 00000003 800e3346 3f8008e0 00000003 3f800e4c
stack_dump: 0x3f8008c0: 00000022 3f800870 00000008 4de28520 800dce7b 3f800900 3f800e48 400d95e4
stack_dump: 0x3f8008e0: 00000022 3f800710 00000000 3f800848 800db283 3f800920 00000000 3f404241
stack_dump: 0x3f800900: 3f800e4c 3f800e4d 3f800b68 3f8001a8 800dabb8 3f800940 3f800b68 3f800e38
stack_dump: 0x3f800920: 3f800e38 400dacb4 00000000 3f800e48 800da55c 3f8009a0 3f800b68 00000001
stack_dump: 0x3f800940: 00000000 00000000 00004124 00000000 00000000 00000000 00000000 00000000
stack_dump: 0x3f800960: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000a
stack_dump: 0x3f800980: 3f404241 00000000 00004000 00000001 800da681 3f8009c0 00000001 00000000
stack_dump: 0x3f8009a0: 3f8009c0 400db158 3f800df0 3f800b68 800d97b9 3f800a80 3f800b68 3f800df0
stack_dump: 0x3f8009c0: 3f800df0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
stack_dump: 0x3f8009e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
stack_dump: 0x3f800a00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3f800df0
stack_dump: 0x3f800a20: 00000003 00000000 00000000 3f800b68 800d9792 3f800df3 3f800df0 00000040
stack_dump: 0x3f800a40: 00000001 3ffaf900 00000000 3f800b68 00000000 400d9838 00000002 00000000
stack_dump: 0x3f800a60: 3f800b68 3f800d68 00000000 00000000 800d956b 3f800ab0 3f800b68 3f800df0
stack_dump: 0x3f800a80: 00000001 3f800ab0 3f800b68 3f800df0 00000001 3f800d68 0000000a 3f800df0
stack_dump: 0x3f800aa0: 800d9527 3f800ad0 00000001 3f800380 00000001 3f403f3b 00060020 3ffb0488
stack_dump: 0x3f800ac0: 800d5fb0 3f800af0 00000001 3f800380 3f800b68 3ffe0c40 00000000 00000000
stack_dump: 0x3f800ae0: 800d3bd7 3f800b20 400d94fc 00000001 00000064 00000000 00000000 00000000
stack_dump: 0x3f800b00: 3f40e19c 3ffb00d8 00000001 00000000 00000000 3f800b40 00000000 00000000
stack_dump: 0x3f800b20: 3f800380 00000100 0000000f 0fffffff 00000000 3f800b60 00000000 00000000
stack_dump: 0x3f800b40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 dev/
 proc/

[royfengsss]

The assertion is because that the memory from user heap would be freed via kmm_free.

asprintf was used in fs/vfs/fs_dir.c, it acturally call lib_malloc to alloc the memory. And this memory pointer will be freed via lib_free in the same source file.

lib_malloc is defined as macro and it will be expanded to kmm_alloc if __KERNEL__ is defined or malloc if __KERNEL__ is not defined.
lib_free is defined as macro and it will be expanded to kmm_free if __KERNEL__ is defined or free if __KERNEL__ is not defined.

The fs module was build with __KERNEL__ defined, so if lib_free is direct used in this modue, it will be kmm_free. While asprintf is defined libc module, and this module (libc) is not build with __KERNEL__ defined. So, the lib_malloc in libc is malloc.

The config option CONFIG_ESP32_SPIRAM_USER_HEAP was enabled, there are two different heaps in system. (Please see #8166). Under this condition, kmm_malloc is not equal to malloc, kmm_free is not equal to free any more.

So the wrong heap error has been cached by assert in kmm_free.

[royfengsss]

#9600 is a simple fix that I can think out. It obligate use malloc under flat build mode, whatever __KERNEL__ is defined. The idea behind it is under flat build mode, there is no boundary between kernel and user app acturally in my personal idea.