fix(task): Fix memory leak from task::run_on_core_nonblocking
#388
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.
Description
vTaskDelete(nullptr)
from the end of the thread functionMotivation and Context
vTaskDelete(nullptr)
was added as part of #353 based on spec. It was erroneously causing the detached thread to leak memory for each call torun_on_core_nonblocking
. Using esp heap tracing I was able to determine that it did leak memory, while the updated code does not leak memory. Additionally, I used theTaskMonitor
to ensure that the tasks are properly destroyed and are no longer registered within the system.Note: as mentioned in the esp-docs, there will be some leaks reported which are benign. What is important is that as we vary the number of times that
run_on_core_nonblocking
is called, that the reported heap trace does not change.For reference, here is the reported trace when calling
run_on_core_nonblocking
twice within a loop which runs 10x. This is the same report as if you ran the loop 1x or 5x.How has this been tested?
task/example
on QtPy ESP32s3 and ensure it works still.task/example
on QtPy ESP32s3 which as freertos runtime stats (for task monitoring) and heap tracing enabled. Dump the heap trace output to ensure the residual memory allocated is not dependent on the number of timesrun_on_core_nonblocking
was called. Confirmed that when includingvTaskDelay(nullptr)
the memory allocated (and leaked) is dependent on the number of times it is called.Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):
Types of changes
Checklist:
Software
.github/workflows/build.yml
file to add my new test to the automated cloud build github action.