tests/thread_priority_inversion: Fails on AVR

[maribu]

Description

From https://hil.riot-os.org/results/riot_tests/51/arduino-mega2560/tests_thread_priority_inversion/console_log.html

make: Entering directory '/opt/jenkins/workspace/riot_tests/tests/thread_priority_inversion'
r
/opt/RIOT/dist/tools/pyterm/pyterm -p "/dev/hil/dut" -b "9600" --no-reconnect --noprefix --no-repeat-command-on-empty-line 
Twisted not available, please install it if you want to use pyterm's JSON capabilities
Connect to serial port /dev/hil/dut
Welcome to pyterm!
Type '/exit' to exit.
Help: Press s to start test, r to print it is ready
READY
s
START
main(): This is RIOT! (Version: buildtest)
low priority thread has started
low priority thread started to work on its task
high priority thread has started
low priority thread is done
mid priority thread has started
mid priority thread started to work on its task
mid priority thread is done
{ "threads": [{ "name": "mid, "stack_size": 256, "stack_used": 74}]}
high priority thread started to work on its task
high priority thread is done
{ "threads": [{ "name": "high, "stack_size": 256, "stack_used": 74}]}
{ "threads": [{ "name": "low, "stack_size": 256, "stack_used": 82}]}
==> Priority inversion occurred
TEST FAILED

Traceback (most recent call last):
  File "/opt/jenkins/workspace/riot_tests/tests/thread_priority_inversion/tests/01-run.py", line 21, in 
    sys.exit(run(testfunc))
  File "/opt/RIOT/dist/pythonlibs/testrunner/__init__.py", line 30, in run
    testfunc(child)
  File "/opt/jenkins/workspace/riot_tests/tests/thread_priority_inversion/tests/01-run.py", line 17, in testfunc
    assert child.match.group(1) == "PASSED"
AssertionError
make: *** [/opt/RIOT/Makefile.include:784: test] Error 1
make: Leaving directory '/opt/jenkins/workspace/riot_tests/tests/thread_priority_inversion'

See #18544 (comment)

Steps to reproduce the issue

make BOARD=arduino-mega2560 -C tests/thread_priority_inversion

Expected results

Test passes

Actual results

Test fails

Versions

Current master

[maribu]

I had a look into this on Friday and failed to really pin down the cause of the issue. I have the feeling that the tread exiting code is buggy on AVR. This seems to be another interesting debugging challenge.