[BUG] Deadlock when ending task scheduler on POSIX #1217
Comments
|
Hello @denravonska, |
How long are you waiting? I modified the code a bit and tried and cannot reproduce.
|
|
Tried it with this script: #!/bin/bash
counter=0
while true; do
echo -n "$counter "
./test.out
let counter++
doneHung on run:
|
|
Adding the config we're using if it helps. |
|
I tried to build with the config and got a build error: I can define the value but wanted to know what do you have for it? |
|
Can you actually provide the whole application and email me at [email protected] |
That's really weird. We don't define I have sent you a binary built with the following: gcc -static -o freeze -O2 -g -ggdb \
-I ../third-party/freertos/config \
-I $FREERTOS_ROOT/include \
-I $FREERTOS_ROOT/portable/ThirdParty/GCC/Posix \
src/main.cpp \
$FREERTOS_ROOT/*.c \
$FREERTOS_ROOT/portable/ThirdParty/GCC/Posix/port.c \
$FREERTOS_ROOT/portable/ThirdParty/GCC/Posix/utils/wait_for_event.c \
$FREERTOS_ROOT/portable/MemMang/heap_4.cwhere |
|
I did some more testing with the config from #include <FreeRTOS.h>
#include <task.h>
#include <stdio.h>
void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName)
{
printf("OVERFLOW!\n");
}
void Task(void *)
{
vTaskEndScheduler();
vTaskDelete(nullptr);
}
int main(int argc, char ** argv)
{
xTaskCreate(Task, "MainTask", 256, nullptr, 4, nullptr);
vTaskStartScheduler();
printf("Done\n");
return 0;
}Edit: I've also switched laptops and I get it on Arch in addition to Ubuntu. |
|
The document that you emailed me isn't the correct one, can you send me a valid zip or tar file |
|
I'm not sure what you mean. It's a minimal binary that has the deadlock issue. If you need the source code rather than the binary it's in the post above. |
|
I've encountered same issue with slightly modifying example app: https://forums.freertos.org/t/freertos-hangs-after-vtaskendscheduler-in-posix-gcc-port/22287 |
|
Now we are seeing it when our test runner calls So it might not just be limited to |
|
Would you please try the following patch - posix_port.patch? |
Tested with this example and I can't reproduce it with the patch applied. Without it it still hangs after around 1k iterations, with it it's still running after Edit: Turned it off after 4 million iterations. |
|
I just want to confirm that we can reasonably conclude that the patch addresses the problem? |
I can confirm that this fixes both my problems:
|
|
Thank you for confirming! |
|
Looking at the documentation it might be a good idea to incorporate this:
|
Prevent application hangs that occur when a thread dies while holding a mutex, particularly during vTaskEndScheduler or exit calls. This is achieved by setting the PTHREAD_MUTEX_ROBUST attribute on the mutex. Fixes: - GitHub issue: FreeRTOS#1217 - Forum thread: freertos.org/t/22287 Signed-off-by: Gaurav Aggarwal <[email protected]>
|
Sure, thank you for the suggestion! I have raised the following PR -#1233. Would be grateful if you can give it a try as well. |
Tested and it seems to be working fine. Thanks! |
Mark mutex as robust to prevent deadlocks Prevent application hangs that occur when a thread dies while holding a mutex, particularly during vTaskEndScheduler or exit calls. This is achieved by setting the PTHREAD_MUTEX_ROBUST attribute on the mutex. Fixes: - GitHub issue: #1217 - Forum thread: freertos.org/t/22287 Signed-off-by: Gaurav Aggarwal <[email protected]>
|
Thank you @denravonska for reporting the issue and testing the fix! |
Describe the bug
We have a unit test runner that spawns a FreeRTOS task that runs our test suite and then calls
vTaskEndSchedulerto allow the main function to exit. This works most of the time but we noticed that there's an occasional deadlock.Target
Host
To Reproduce
Example code:
Running this in a loop helps triggering the issue. For me it triggers faster if I switch to another terminal:
Looking at the threads we can see that the main task is stuck trying to take a mutex:
What's interesting is, if I interpret this correctly, that the mutex owner no longer exists:
The text was updated successfully, but these errors were encountered: