Deadlock @ mdns_free() (IDFGH-718) #1696
Assignees
Labels
Type: Bug
bugs in IDF
Comments
|
Suggested fix: I was able to reproduce this easily with softAP created on ubuntu machine. |
github-actions
bot
changed the title
|
Hi, this bug has already been addressed in 6bb68a5 and 206b47c. There's still one possible deadlock (yet very improbable) calling |
igrr
pushed a commit
that referenced
this issue
Mar 14, 2019
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes #1696
igrr
pushed a commit
that referenced
this issue
Mar 17, 2019
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes #1696
catalinio
pushed a commit
to catalinio/pycom-esp-idf
that referenced
this issue
Jun 28, 2019
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696
david-cermak
added a commit
to david-cermak/esp-protocols
that referenced
this issue
Mar 24, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
Mar 25, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
Apr 8, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
May 17, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
May 27, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
May 27, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
gabsuren
pushed a commit
to gabsuren/esp-protocols-1
that referenced
this issue
May 27, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
0xFEEDC0DE64
pushed a commit
to 0xFEEDC0DE64/esp-protocols
that referenced
this issue
Jun 30, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
euripedesrocha
pushed a commit
to euripedesrocha/esp-protocols
that referenced
this issue
Oct 17, 2022
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task Closes espressif/esp-idf#1696 * Original commit: espressif/esp-idf@48b5501
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
mdns_free() calls function _mdns_service_task_stop()
mdns_free() --> _mdns_service_task_stop() {
MDNS_SERVICE_LOCK() --> Step 1
Post ACTION_TASK_STOP to task and wait on this while loop
while (_mdns_service_task_handle) {
vTaskDelay(10 / portTICK_PERIOD_MS);
}
MDNS_SERVICE_UNLOCK();
}
on _mdns_service_task() {
Wait on queue messages() --> Step 2
if(action == ACTION_TASK_STOP)
{
break; //exit the task
}
MDNS_SERVICE_LOCK(); --> Step 3
_mdns_execute_action(a);
MDNS_SERVICE_UNLOCK();
}
If Step 1 happens and on Step2 if there are other actions pending on queue mdns task will be stuck at Step3
This can be easily reproduced if mdns_service_remove_all() is called just before mdns_free(). (happens 1 in 10 times)
The text was updated successfully, but these errors were encountered: