-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(cortex-m) unexpected kernel panic after thread exit #20812
Comments
I could not reproduce this issue on Maybe there is a specific issue on your toolchain or newlib package from Ubuntu. |
I've used ARM GCC toolchain 13.3 (downloaded from the website, placed it in /opt/tools and added it to my path variable). Which toolchain did you use? I believe this problem only occurs when the scheduler is being triggered from an interrupt. When after exiting the one thread another busy task starts it won't occur (if I remember correct😉). Tomorrow I can perform some tests with different toolchains myself. It could indeed be an issue with my newlib/toolchain, but this one function assumes that a pointer isn't null where by its surrounding comment it can be (and is being set to null by at least one function). |
Ok, I've misread the reported toolchain. |
I can reproduce the issue. It occurs only when the feature
I'll try to PR a proper fix soonish. |
The function `sched_switch()` was implemented with the assumption that there will always be an active thread. This was true until threadless idle was implemented for Cortex M MCUs: If no thread is runnable and the running thread exists, there will be no active thread. If from ISR a thread is then unblocked, `sched_switch()` will be called without an active thread. This handles the corner case explicitly when the module `core_idle_thread` is not used (in other words: for threadless idle). Fixes RIOT-OS#20812
Description
I've noticed an unexpected kernel panic after a thread exited. I've traced it down to
sched_switch
incore/sched.c
retrieving an invalid active thread. Insidesched_task_exit
, thesched_active_thread
pointer is being set to NULL andsched_switch
does not check if the retrieved thread pointer points to a valid thread.Steps to reproduce the issue
I have created a small application that triggers the problem (tested on an STM32 NUCLEO-F401RE, problem initially seen on an EFR32). It uses the
shell
module as the problem is triggered when the scheduler is invoked. After starting the application, enter a character in the console/terminal to invoke the scheduler.Inside
core/sched.c
I've added an assertion to enforce the problem (without it sometimes magically goes well).main.c
Expected results
After accessing the console, I would expect the system to stay alive ;)
Actual results
After entering an enter character in the console, I get the following panic and stack trace.
Potential Fix
I've changed
sched_switch
to include a check for active thread being valid to deal with threads having exited.I don't know if
sched_switch
must be able to deal with this case or ifsched_task_exit
shouldn't set thesched_active_thread
to NULL. The comment aroundthread_get_active
indicates the first. In that case we need to check if there are other functions that cannot deal with this case and potentially add assertions to help finding those cases in the future.Versions
RIOT version: master (5267300)
The text was updated successfully, but these errors were encountered: