POSIX Simulator: Handle pthreads not created by FreeRTOS differently

[johnboiles]

Avoid calling pthread_sigmask on pthreads not created by FreeRTOS. Also avoids waiting forever on vPortEndScheduler if that's called from a non-FreeRTOS thread.

Description

This PR modifies the behavior of the FreeRTOS POSIX simulator. The tick handler (via sigaction) might happen on any thread in the current process. This can cause hangs with non-FreeRTOS threads (because they can get hung when prvSuspendSelf is called on them.

Test Steps

Run this program against the main branch, notice that it hangs on shutdown.

#include <freertos/FreeRTOS.h>
#include <freertos/task.h>
#include <thread>
#include <iostream>
#include <unistd.h>

void appMainTask(void *parameters) {
    while (true) {}
    vTaskDelete(NULL);
}

bool mainLoop() {
    static bool shouldRun = true;
    if (std::cin.peek() != EOF) {
        char input;
        std::cin >> input;
        if (input == 'q') {
            shouldRun = false;
        }
    }
    return shouldRun;
}

auto main(int argc, char *argv[]) -> int {
    // Start the FreeRTOS scheduler
    std::thread schedulerThread([]() {
        xTaskCreate(appMainTask, "app_main", 10000, NULL, 1, NULL);
        vTaskStartScheduler();
        printf("Scheduler thread done\n");
    });

    while (mainLoop()) {
        // Limit to ~60fps so we don't murder battery unnecessarily
        usleep(1000000.0 / 60.0);
    }

    vTaskEndScheduler();
    schedulerThread.join();

    return 0;
}

Now run it again with this change and notice that it shuts down cleanly.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

I still need to read up on the test suite. Looking for directional feedback first.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.61%. Comparing base (31dd1e3) to head (aa8fcad).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1223      +/-   ##
==========================================
- Coverage   91.64%   91.61%   -0.03%     
==========================================
  Files           6        6              
  Lines        3254     3257       +3     
  Branches      903      901       -2     
==========================================
+ Hits         2982     2984       +2     
  Misses        132      132              
- Partials      140      141       +1     

Flag	Coverage Δ
unittests	91.61% <ø> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aggarg]

The aim of the POSIX port is to aid development of FreeRTOS applications. Why would you want to create native pthreads in a FreeRTOS application?

[johnboiles]

A simulator program may need other threads to simulate peripheral hardware. For example I need another thread to run my virtual display window that simulates my hardware display. My main FreeRTOS application does not need to know about my display simulator.

On some platforms (I'm experimenting with iOS) the system frameworks create several threads at startup so there are already other threads existing when user code is run. Running my FreeRTOS code on iOS is useful to me as it allows me to easily prototype peripherals like touch screens and HDMI output without bringing up the target hardware (which we haven't received yet).

The current FreeRTOS implementation eventually causes all other threads to lock up.

[hoxi]

We’re also using separate (non-FreeRTOS) pthreads to simulate various interrupt sources, and this change aligns well with a pull request we plan to submit. In our case, the interrupt pthreads call different FreeRTOS ISR APIs to inject data into the FreeRTOS application. For this to work, we’ve added an additional port mutex layer to prevent ISR APIs from being executed while FreeRTOS is in a critical section. It would be great to see this patch merged in some form so that we can rebase our planned pull request onto it.

[jasonpcarroll]

This is a great change, and its clear that other users find it valuable as well. Thank you! I just had some minor comments regarding early returns - mainly just to make static analyzers happy since MISRA C will flag it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jasonpcarroll]

Hmm a check is failing but it doesn't seem related to your change... I will look into it.

[jasonpcarroll]

For now, we will merge this as there is no action needed on this PR. Thanks @johnboiles!

[johnboiles]

Thanks for getting this in there!

[denravonska]

Are leak checks a port of the CI? After switching to main we started noticing memory leaks in our tests and I'm trying to figure out if it's due to this PR or if we're shutting down incorrectly.

Direct leak of 1 byte(s) in 1 object(s) allocated from:
    #0 0x7ffff78fd891 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5555557ab096 in prvMarkAsFreeRTOSThread ../third-party/freertos/repo/portable/ThirdParty/GCC/Posix/port.c:155
    #2 0x7ffff6aa32cd  (/usr/lib/libc.so.6+0x942cd) (BuildId: aed3a2b0cf4e6cc12296052529af22f6a450a75a)

Edit: Seems to only happen in one of our test suites so I think it's something on our end.
Edit: It was on my end. Interestingly, killing all threads via vTaskEndScheduler then killing the thread again via a C++ destructor will show up as a memory leak.

[aggarg]

Thank you for sharing! Which tool are you using for finding these leaks?