[BUG] Delete a task in competition will cause a crash about freertos HOT 3 CLOSED

Hi @yellowbeeHYF ,

I have looked into this one carefully as we are always concerned about things that look like concurrency problems. Thank you for doing a very thorough report, that made it a lot easier to investigate!

My conclusion is that this is not actually a bug in FreeRTOS, but rather an incorrect usage of the API. I also think that we can definitely be more specific about the limitations here so we will be updating the documentation in the API reference to call this case out specifically for vTaskDelete.

The root cause of the crash you are seeing is that vTaskDelete is called more than once for the same task. If you simply called vTaskDelete twice in a row for the same task you would see the same behavior. The kernel cannot reasonably keep track of old deleted tasks to prevent you from deleting them again as this would cause a significant performance hit and also does not solve the memory re-use case.

Task handles are just pointers to the location of the TCB, and an even worse scenario would be if TaskA were to kill itself, a new task was created using the same memory, resulting in the same TCB pointer, and then task B attempts to delete TaskA, but now it is actually deleting a different task entirely. This is the memory re-use case.

If you think about it this is really a classic race condition which applications always have to guard against. If a task called vPortFree on a block of memory, and a different task called vPortFree on a pointer holding the same address you would of course see a similar situation.

My recommendation would be that if you are going to delete a task from more than one context you need to protect against the deletion using a mutex or semaphore. In this case you could keep the task handle in a shared location which is protected by a mutex, and let the deleting task set the pointer to NULL before delting the task. This way when TaskB decides that it wants to delete TaskA it will find the pointer set to NULL and know that task A has already been deleted, which means it will not call vTaskDelete at all.

An even better solution is to never delete a task from more than one context. This can be achieved by sending a message to the task to delete itself (you could use direct to task notifications or even atomics to achieve this), or alternatively let the task send a message to a coordinating task that does all of the deleting in a single context.

Cobus

from freertos.

Another solution to add to the list of recommendations provided by @cobusve , is to ref-count the deletions using an atomic variable.
This way you will ensure that the last owner of the task will be the only one to actually call delete.

An example can be found here:
https://github.com/aws/amazon-freertos/blob/master/libraries/abstractions/secure_sockets/lwip/iot_secure_sockets.c#L189-L203

Alfred

from freertos.

I am closing this issue as there has been no response about the assessment.

from freertos.