casaroli opened a new pull request, #19790: URL: https://github.com/apache/nuttx/pull/19790
## Summary A full `ostest` run never reached the end on `esp32-devkitc:knsh`. It stopped in the barrier test: ``` barrier_test: ERROR thread 6 create, status=12 barrier_test: Test aborted with waiting threads ostest_main: Exiting with status 256 ``` This lowers the barrier thread count for that configuration, and the run completes. ## Cause Two settings that are each reasonable on their own. `CONFIG_TLS_ALIGNED` is set and `CONFIG_TLS_LOG2_MAXSTACK` is 13, so every pthread stack must begin on an 8 KiB boundary. The barrier threads take the 2 KiB default stack, so each one occupies an 8 KiB aligned slot — four times what it uses. A protected build has a 96 KiB user heap. Eight aligned slots do not fit it once the tests before the barrier have fragmented it, and the allocation fails: ``` up_create_stack: ERROR: Failed to allocate stack, size 2048 ``` The flat build has the same two settings and passes, because its heap is 320 KiB against 96 KiB here. That is the whole difference. Two things this is **not**, both measured rather than assumed. It is not the user heap running out: 75,544 bytes were free with a 47,096 byte largest block when a 2048 byte request failed. It is not the kernel heap: raising `CONFIG_MM_KERNEL_HEAPSIZE` from 8 KiB to 32 KiB changed nothing, and the failure stayed on thread 6 exactly. ## Why not grow the heap instead The user heap cannot grow far. User data has to sit in the MMU governed window of SRAM2, `0x3ffc0000` to `0x3ffdffff`, which is 128 KiB in total, and the kernel currently holds the first 32 KiB of it. Recovering that would move the kernel/user boundary and the per-page access rights in `esp32_userspace.c`, which is a larger change to an experimental subsystem and does not belong in a fix for a test configuration. Four threads still test a barrier. They also leave margin: six was the most that ever started, so six would pass with none at all. ## Testing Board: ESP32-DevKitC V4, with an ESP32-D0WD-V3 revision 3.1. Host: macOS 15 on Apple Silicon, `xtensa-esp32-elf-gcc` 12.2.0. Configured from the edited `defconfig` after a `distclean`, so the result comes from the committed file: ``` barrier_test: Thread 0 completed with result=0 barrier_test: Thread 1 completed with result=0 barrier_test: Thread 2 completed with result=0 barrier_test: Thread 3 completed with result=0 ... ostest_main: Exiting with status 0 ``` Before this change the same board and toolchain gave `Exiting with status 256`. `tools/checkpatch.sh -c -u -m -g` reports no errors. -- 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]
