Ci fix esp32s2 wifi - #2382
Open
petermm wants to merge 3 commits into
Open
Conversation
The ESP32 event queue and queue set are process-global, but every test VM initialized them again and overwrote the existing handles. Each invocation leaked both FreeRTOS allocations and gradually exhausted heap on memory-constrained targets. Make queue initialization idempotent and drain retained sender events in the test harness before creating each new GlobalContext. Draining through the queue set prevents stale pointers from a destroyed VM from being delivered to the next one without adding test lifecycle handling to production firmware. Use an explicit void parameter list for the queue initializer declaration and definition. Signed-off-by: Peter M <petermm@gmail.com>
globalcontext_destroy did not release live contexts, the module index and hash table, or the atom table. Repeated test VMs therefore steadily exhausted heap on memory-constrained targets. Add a ValuesHashTable destructor, use it in initialization failure paths and final teardown, destroy remaining contexts, and exercise hash-table destruction in the structure test. Signed-off-by: Peter M <petermm@gmail.com>
network:start allocates ClientData shared by registered event handlers, but teardown only unregistered the callbacks. Repeated network-driver lifecycles therefore leaked the allocation. Track the callback data in ESP32PlatformData and release it after the handlers, Wi-Fi driver, and network interfaces are shut down. Signed-off-by: Peter M <petermm@gmail.com>
petermm
force-pushed
the
ci-fix-esp32s2-wifi-harness
branch
from
August 21, 2026 09:20
13bbf17 to
5289683
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ESP32 CI harness had a leak of the xQueue - LLM estimated close to 0.5kb times 22 leaks for a total of around 10kb leak.
Heap instrumentation with the queue fix already applied showed a further drop from approximately 75,288 to 63,744 bytes of free heap across repeated Wi-Fi teardown and reinitialization: about 11.5kb of additional retained memory.
A smaller leak came from the ESP32 network driver. Each
network:start/1allocated a 32-byteClientDatastructure, plus allocator metadata, which was not released after unregistering the event handlers. This is approximately 0.04kb per network start, or around 0.1kb for the three Wi-Fi starts exercised by the ESP32-S2 test run.Together with the queue leak, the harness was retaining roughly 21-22kb of heap during the test run. This was enough to prevent the Wi-Fi driver from allocating all of its static RX buffers on memory-constrained ESP32-S2 configurations.
The fixes:
ValuesHashTabledestructor and use it in initialization failure paths and final teardown.globalcontext_destroy().These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later