tests/kernel/thread_apis: Fix essential thread abort test

This test was buggy.  The first call to k_thread_abort() would
terminate the calling thread (because it handled a panic!) and so the
second case (an essential thread self-aborting) wasn't actually being
exercised and was silently "passing".  Oops.

Fix by splitting the cases into two tests, as suggested by @fsammoura

But unmasking that shows that there are some arch buglets[1] to fix
before this case can pass for everyone.  So skip on x86/riscv/sparc
for now.

[1] See the comment.  It's not really a "bug" as we've never demanded
that arch layers do this.  But it does work on many of them.

Signed-off-by: Andy Ross <andyross@google.com>
This commit is contained in:
Andy Ross 2025-02-21 11:59:09 -08:00 committed by Fabio Baltieri
commit 706dd25561

View file

@ -112,6 +112,22 @@ ZTEST(threads_lifecycle, test_essential_thread_abort)
k_msleep(100);
k_thread_abort(&kthread_thread1);
zassert_true(fatal_error_signaled, "fatal error was not signaled");
}
ZTEST(threads_lifecycle, test_essential_thread_abort_self)
{
/* This test case needs to be able to handle a k_panic() call
* that aborts the current thread inside of the panic handler
* itself. That's putting a lot of strain on the arch layer
* to handle things that haven't traditionally been required.
* These ones aren't there yet.
*
* But run it for everyone else to catch regressions in the
* code we are actually trying to test.
*/
if (IS_ENABLED(CONFIG_RISCV) || IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_SPARC)) {
ztest_test_skip();
}
fatal_error_signaled = false;
k_thread_create(&kthread_thread1, kthread_stack, STACKSIZE,