Kernel panic on QEMU when switching between fullscreen to default

[rilysh]

Trying to switch between fullscreen to default screen and also pressing standard shortcut keys at the same time, TinkerOS may yield a kernel panic.

Screenshot

QEMU: 7.2.9 TinkerOS: 5.13

Apologize for editing the title two times...I mistakenly clicked enter so GitHub just created the issue without the actual context.

[tinkeros]

I tried same version of QEMU on Debian 12.1 with and without KVM acceleration and tried running with only 1 core and was unable to reproduce the issue using CTRL-ALT-F to switch between full screen and windowed mode. Can you please try to provide me any more information about what might help reproduce it on my end?

Here's what I did: https://youtu.be/hGSDMW_KfSU

[tinkeros]

Let me know what other keys I might try pressing to reproduce it. I suspect based on the image TOS thinks you pressed CTRL-ALT-d (maybe some keyboard bug in QEMU related to you pressing something similar like ALT-D to enter the file manager and some how later it thinks the CTRL key is down too with them)? It looks like a crash triggered by CTRL-ALT-D.

If it happens again, try not to move the mouse (to avoid the garbage characters) and try running CallerRep. This is what I get when I press CTRL-ALT-D and run CallerRep;

[rilysh]

Thanks! Indeed, pressing CTRL+ALT+d raises a panic.

But I've also seen this issue while pressing CTRL+s on rare occasions. For example, I ran a QEMU VM for about ten minutes, and played a few games inside of it. After closing the game window, when I came back to the left side terminal (where this text: Public Domain Operating System) and pressed CTRL+s, it crashed again.

This time, however, I wasn't able to unlock my mouse from QEMU (QEMU bug?). I had to kill the QEMU process from a different console. These issues also exist on TempleOS as well, which I downloaded from here.

[tinkeros]

Ok, so it seems Terry does something sketchy (wouldn't be the first time) in DocMenu by making a task end callback which throws an exception to cleanup the menu: DocMenuEndTaskCB. This is not really elegant, though works in most cases.

I can envision cases where this won't always work gracefully for example I can reproduce your crash by doing the following: Press CTRL-D to open file manger Selecting a file and hitting ENTER to bring up the choices (calls DocMenu) Press CTRL-D (at least once, possibly more times) to open a new file manager in the DocMenu window (you shouldn't do this). Then open a file with the space bar to DolDoc edit it inside this DocMenu window Once open, press ESC to exit the editor and crash your system to the debugger.

https://youtu.be/i-5GIUrbsMY

It's not clear to me what your use case is that you are running into this, however I would say don't use a window created by a call to DocMenu to do other stuff in (for example in my crash I opened the file DoDistro.HC.Z inside an editor inside the window that was the menu used by the first file manager).

It may be the case that whatever you are doing you ought to open a new terminal before doing it or be exiting a menu before pressing the keys you are pressing.

There are a lot of unhandled situations in TempleOS/TinkerOS which may be considered as bugs by some people and just things to be aware of by other people. What I did to reproduce the crash I would not really consider a major bug, it is more me using the system in an unintended way. Not knowing what you did kind of makes it hard to judge if this is really something a lot of people encounter or if it is just you using the system in a unique way most people don't?

I'll think about this more and maybe consider changing it to behave more gracefully for this particular thrown exception in my next release. I suspect whenever you do encounter this error if you simply type Exit; when you enter the debugger you will be gracefully returned to they system in a decent state.

If you can produce steps which you think other people might also do which causes this and Exit doesn't return the system to a graceful state, I'd be interested to hear.

[rilysh]

What I did to reproduce the crash I would not really consider a major bug, it is more me using the system in an unintended way. Not knowing what you did kind of makes it hard to judge if this is really something a lot of people encounter or if it is just you using the system in a unique way most people don't?

I don't really fiddle a lot with TempleOS, just re-downloaded it yesterday after seeing TinkerOS. What I did was closed all open "command windows" and only kept the above logging window and the blue background screen. Pressed CTRL+s and encountered with that unhandled exception.

I think I can call it an edge case. Not knowing what just happened, many will just reboot the system. Apparently, I didn't know that you can type "Exit;" to ignore that state, so that's something cool.

If you can produce steps which you think other people might also do which causes this and Exit doesn't return the system to a graceful state, I'd be interested to hear.

Creating this one (https://github.com/tinkeros/TinkerOS/issues/9#issuecomment-2016581558) (CTRL+ALT+d) and if I type "Exit;", it doesn't exit the debugger state.

[ljward2]

Exit should not work for the case when you purposefully enter the Debugger with CTRL-ALT-D. It does work for all cases I've encountered where you enter the debugger because DocMenuEndTaskCB got called when in a state where the exception isn't ready to be caught that I've come up with. I have a fix which works fine for my contrived case to generate the error, but like I said if you had another set of steps to produce the error triggered by DocMenuEndTaskCB where running Exit doesn't leave you in a clean state then I would worry about my fix. All I know is the fix doesn't cause issues with my unit tests and the OSTestSuite. Unless I hear otherwise from you, I'll likely incorporate it in my next release if I don't see any other issues after testing it awhile and pondering the issue.

[rilysh]

I see, so that shortcut is meant to enter to the debugger. Thanks for the explanation!

[ljward2]

Yes, originally I thought you were possibly entering the debugger by accident or through some strange QEMU keyboard bug, but now I'm assuming based on your CallerRep it is related to this other issue with DocMenuEndTaskCB and the way DocMenu is implemented.

[tinkeros]

If you want you can give this pre-release a shot and see if it fixes your issue.

[rilysh]

Thanks, I'll check this out later this afternoon.