mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-22 16:06:57 +00:00
This test has a problem, specifically in the scenario for test_mem_domain_remove_partitions. A low priority thread (10) is created which is expected to produce an exception. Then the following happens: - The thread indeed crashes and ends up in the custom fatal error handler, on the stack used for exceptions - The call to ztest_test_pass() is made - ztest_test_pass() gives the test_end_signal semaphore - We then context switch to the ztest main thread which is higher priority, leaving the thread that crashed context switched out *on the exception stack* - More tests are run, and some of them also produce exceptions - Eventually we do a sleep and the original crashed thread is swapped in again - Since several other exceptions have taken place on the exception stack since then, resuming context results in an unexpected error, causing the test to fail Only seems to affect arches that have a dedicated stack for exceptions, like x86_64. For now, increase the priority of the child thread so it's cleaned up immediately. Longer-term, this all needs to be re-thought in the test case to make this less fragile. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com> |
||
---|---|---|
.. | ||
futex | ||
mem_protect | ||
obj_validation | ||
protection | ||
stack_random | ||
stackprot | ||
sys_sem | ||
syscalls | ||
userspace |