Kernel: Panic if ^C is followed by ^Z too quickly

[oskar-skog]

^C followed by ^Z too quickly sometimes ends in a panic, at least on riscv64

[python3.14(59:59)]: KERNEL PANIC! :^(
[python3.14(59:59)]: Attempting to stop with invalid thread state - Dying
[python3.14(59:59)]: at ./Kernel/Tasks/Thread.cpp:1218 in void Kernel::Thread::set_state(State, u8)
Kernel + 0x00000000003193c4  Kernel::__panic(char const*, unsigned int, char const*) +0x138
Kernel + 0x0000000000453a7e  Kernel::Thread::set_state(Kernel::Thread::State, unsigned char) +0x3d4
Kernel + 0x000000000045934c  Kernel::Thread::dispatch_signal(unsigned char) +0xa38
Kernel + 0x000000000045b01a  Kernel::Thread::check_dispatch_pending_signal(Kernel::YieldBehavior) +0xd0
Kernel + 0x00000000000077c0  Kernel::ProcessorBase::exit_trap(Kernel::TrapFrame&, bool) +0x82
Kernel + 0x00000000004911ca  restore_context_and_sret +0x0

[spholz]

@implicitfield we were pretty sure that this can't happen in #26180/#26160. Seems like it actually is somehow?

[spholz]

Oh I read the part that says "- Dying" as that we are going to die (panic) now. But it seems like this is the previous state?

I wonder what we should do here. Stopping a dying thread seems wrong.

[implicitfield]

Yeah, that just means that m_state == Thread::State::Dying. We probably just shouldn't dispatch signals to dying threads in ProcessorBase::exit_trap. I guess the old scheduler-driven signal dispatching might not have had this issue since I doubt that we schedule dying threads in the first place.