When I'm in JNode commandline and perform
| Project: | JNode Core |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
When I'm in JNode commandline and perform a command that takes a while to execute (I used 'play') and press Ctrl-C really quick after executing the command, JNode will return the following:
JNode /> play
ctrl-c: Returning focus to console. (null has been killed)
JNode />
This obviously is wrong. Furthermore the command still gets executed fully, it really doesn't get killed.
When I executed play again and pressed Ctrl-C when it was actually playing, it said:
JNode /> play
ctrl-c: Returning focus to console. (play has been killed)
Incorrect threadState in wakeUpByScheduler 00000004 Lock not owned by us .. etc.
And after that a debug stacktrace and a Real Panic line.
- Login to post comments
Ctrl-C with nothing running produces exception
Press Ctrl-C at the prompt a few times with nothing running and you will produce a few exceptions which propigate up through the shell to the thread scheduler. Shouldn't exceptions from the shell prompt be caught and reported by the shell?
Yes ... Ctrl-C is broken.
It has been like this for a long time. As you noticed, when Ctrl-C causes JNode to try to kill the current command, the end result is a kernel panic. This indicates that something is broken at the VM level.
Independent of that, the Ctrl-C is performed by calling Thread.stop() on the command's thread. This is (IMO) a bad idea, for the same reasons that Sun deprecated Thread.stop() and related methods. When you stop a thread, it may be half way through doing an update to an important shared data structure. The result is unpredictable.
IMO, we should probably map Cntrl-C to Thread.interupt() in the current invokers, and just hope that the command is going to notice the interupted state and act appropriately. We should only try to hard kill commands if they are running in a separate isolate. There isn't (yet) an invoker that will run commands in isolates.
Yes, exceptions should be caught
... and I'm soon going to upload a patch that gives the user more control over the emission of stacktraces.
But the I think that the kernel panic is actually happening at the point that the shell is trying to catch the exception. IIRC, there is already an open bug report for that aspect of the Ctrl-C problem.
#1
I'm closing this as won't fix as we need full Isolation to make that someday work.
A better exception handling is in trunk for some time.
Have a look at this issue for status of Isolates.