xTaskCreateWithCaps causing memory leak when deleting. (IDFGH-13294) #14222
Comments
github-actions
bot
changed the title
|
Hi @RoniRaad! TaskHandle_t check_dma_task_handler;
void task1() {
...
xTaskCreateWithCaps( (TaskFunction_t)insta_free_task, "insta_free_task", 2042*3, nullptr, tskIDLE_PRIORITY, check_dma_task_handler, MALLOC_CAP_SPIRAM);
}
void task2(){
...
vTaskDeleteWithCaps(check_dma_task_handler);
} |
|
Hi @KonstantinKondrashov, |
espressif-bot
added
Status: Done
vTaskDeleteWithCaps() leaked memory when a task uses the API to delete itself. This commit adds a fix to avoid the memory leak. Closes espressif#14222 (cherry picked from commit c3da2ac)
vTaskDeleteWithCaps() leaked memory when a task uses the API to delete itself. This commit adds a fix to avoid the memory leak. Closes espressif#14222 (cherry picked from commit c3da2ac)
vTaskDeleteWithCaps() leaked memory when a task uses the API to delete itself. This commit adds a fix to avoid the memory leak. Closes #14222
vTaskDeleteWithCaps() leaked memory when a task uses the API to delete itself. This commit adds a fix to avoid the memory leak. Closes #14222
|
Hi @KonstantinKondrashov ! Applied fix ruined my application logic because I sent a signal to task when it should wrap up, free resources and self delete. Is there a plan to enable tasks with caps to be self deleted? Or it is not possible? |
|
@ermacv What is the current fix breaking in your application? If the task receives a signal to self delete it should create a sub task to do it allowing the resources to be freed as implemented in this fix for vTaskDeleteWithCaps(NULL) |
|
Hi @RoniRaad ! When I want to stop the task I set an event flag and wait for response. It looks like this: if (bits & EVENT_TASK_STOP_REQUEST) {
xEventGroupSetBits(icfg.flags_sync, EVENT_ACTION_DONE);
vTaskDeleteWithCaps(NULL);
}But now this assertion is triggered: assert failed: 0x40396138
0x40396138: __assert_func at /home/ermacv/esp/esp-idf/components/newlib/assert.c:37
Backtrace: 0x40375bfe:0x3fcdb350 0x40385655:0x3fcdb380 0x4039613d:0x3fcdb3b0 0x421441bb:0x3fcdb400
0x40375bfe: panic_abort at /home/ermacv/esp/esp-idf/components/esp_system/panic.c:463
0x40385655: esp_system_abort at /home/ermacv/esp/esp-idf/components/esp_system/port/esp_system_chip.c:92
0x4039613d: __assert_func at /home/ermacv/esp/esp-idf/components/newlib/assert.c:39
0x421441bb: prvTaskDeleteWithCapsTask at /home/ermacv/esp/esp-idf/components/freertos/esp_additions/idf_additions.c:91 (discriminator 1)And it is related to this code that was added in the recent patch: /* The task to be deleted must not be running */
configASSERT( eRunning != eTaskGetState( xTaskToDelete ) ); |
But who will delete the second task?)) |
|
@ermacv looks like it could be a bug in the new code, the vTaskDeleteWithCaps should suspend the task. You could try calling vTaskSuspend(NULL) right after vTaskDeleteWithCaps, but regardless I think this would be a new bug ticket |
Second task is created without caps allowing for it to delete itself without requiring a sub task |
|
@ermacv In your use-case, are you sending an event to the task which must be deleted? I would like to understand the scenario before we can investigate this. It would be good if you could open a new ticket for us, preferably with a minimal demo which could help us reproduce the problem you are facing. Thank you and apologies for the inconvenience! |
espressif-bot
added
Status: Opened
|
@ermacv |
|
Thank you all for response! I will check your comments and respond you. Another question. Will it be ok to stop the task this way? Task code: if (bits & EVENT_TASK_STOP_REQUEST) {
xEventGroupSetBits(icfg.flags_sync, EVENT_ACTION_DONE);
// block task with suspend
vTaskSuspend(NULL);
// or infinite delay
vTaskDelay(portMAX_DELAY);
}Caller of the task stop: xEventGroupSetBits(icfg.flags_sync, EVENT_TASK_STOP_REQUEST);
xEventGroupWaitBits(icfg.flags_sync, EVENT_ACTION_DONE, pdTRUE, pdFALSE, portMAX_DELAY);
vTaskDeleteWithCaps(task_handle);I mean if |
|
@ermacv Could you give some info about your case:
|
|
|
Hi @sudeep-mohanty !
I also attached the |
|
Hm, I didn't notice this comment in the code: I guess my issue could be related to the last sentence in this comment. |
|
Thanks @ermacv for the code. I shall investigate and post my findings. |
espressif-bot
added
Status: Opened
|
Hi @ermacv, Thank you for sharing your code. I could reproduce the issue at my end with some modifications to it. Indeed, the assert failure happens when the system is overloaded and there are multiple unpinned tasks which could get scheduled on the other core before they are deleted. The best way to avoid this issue is what you are already doing, i.e, delete such tasks from another task's context instead of deleting themselves. In case you still have a case of self-deletion, please apply this patch and re-try. Thanks. |
espressif-bot
added
Status: In Progress
vTaskDeleteWithCaps() leaked memory when a task uses the API to delete itself. This commit adds a fix to avoid the memory leak. Closes #14222
espressif-bot
added
Status: Reviewing
espressif-bot
added
Status: Done
This commit fixes an assert failure in vTaskDeleteWithCaps() when multiple un-pinned tasks are created with stack in the external memory and such tasks delete themselves. Closes #14222
This commit fixes an assert failure in vTaskDeleteWithCaps() when multiple un-pinned tasks are created with stack in the external memory and such tasks delete themselves. Closes #14222
This commit fixes an assert failure in vTaskDeleteWithCaps() when multiple un-pinned tasks are created with stack in the external memory and such tasks delete themselves. Closes #14222
Answers checklist.
IDF version.
5.2.2
Espressif SoC revision.
ESP-32-S3
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP-32-S3
Power Supply used.
USB
What is the expected behavior?
When calling vTaskDeleteWithCaps(NULL) from within the task pxTCB and task stack should be freed.
What is the actual behavior?
pxTCB and task stack are not freed and leaking DMA heap and caps memory.
I believe this is due to the last two free's in vTaskDeleteWithCaps being after a call to vTaskDelete which ends the current tasks execution not allowing those two free's to run.
Steps to reproduce.
Debug Logs.
More Information.
code used to reproduce logs.
here is my local fix that modifies vTaskDeleteWithCaps
The text was updated successfully, but these errors were encountered: