Forcibly Kill Crashed JME Program

Often when I am working on my game I accidentally create an infinite loop or other long running task that freezes the game. I have an AppState that will unfocus the mouse when I press escape so I can access my IDE’s debugger (if it’s relevant, I don’t use the SDK but rather IntelliJ Idea). This AppState, however, is ineffective when the game’s main thread is locked up in something. Is there any Linux command (I would execute it via ALT+F2) that will forcibly uncapture the mouse from JME3 or even kill the JME3 game without effecting the other java programs, such as my IDE.

Right now, I am using killall -9 java to get rid of the mouse lock. The issue with this is that it also kills my IDE so I can’t figure out what went wrong. I can’t use xkill, as the game has the mouse captured.

EDIT: I tried the command listed here (xdotool key XF86Ungrab) and it had no effect.

look here:

Basically, create a new thread with endless loop that checks for a variable at the main thread.
If the main thread variable is not updated for more than 500ms, execute this:

EDIT: mmm, I forgot to mention that, you must re-grab the mouse if it detects the application is working again. Basically, the effect here is, everytime my application lags, the mouse ungrabs; as soon it continues, the mouse is re-grabbed. Blends perfectly with debugger.

PS.: I am on linux too and couldnt find a single command outside the application that could ungrab the mouse (well at eclipse IDE it did but… it is still… in the application in some way).

Yeah this is really the one shortcomming on linux, that alt+tab does not ungrab the mouse :smile:
I solved it for the moment, by simply changing to drag to move for the simpler cases.

you can use ps -aux it will display all process then just look for your application pid (should be in the last lines) and use kill $pid and with -9 (SIGKILL) if kill didn’t work

This requires a full Terminal to do which isn’t available via ALT+F4.

Does Windows ungrab the mouse on CTRL+ALT+DELETE?

It ungrabs it on alt-tab in my experience. Just not on Linux.

It occurs to me that some enterprising person could probably bundle all of that (extra thread, flag, etc.) into an AppState and give people a drop-in utility for this.

I just tried to implement it. Unfortunately, it fails if the game is run within Swing (which is useful for proper multi-monitor fullscreen on Linux). What mouse grabbing method does the Swing canvas use?

Here it is for anyone who wants it:


public class UngrabAppState extends AbstractAppState{
    private final Thread thread;
    private volatile long lastUpdate;
    private volatile boolean remove = false;

    public UngrabAppState(){
        thread = new Thread(this::run);

    public void initialize(AppStateManager stateManager, Application app){
        lastUpdate = System.currentTimeMillis();

        thread.setName("Freeze Checker Thread");

    public void update(float tpf){
        lastUpdate = System.currentTimeMillis();

    public void cleanup(){
        remove = true; //this boolean is used in addition to the thread interrupt in case this cleanup method is called while the thread is checking if the mouse needs to be ungrabbed or ungrabbing the mouse

    private void run(){

            if(lastUpdate < (System.currentTimeMillis() - 500L)){

        }catch(InterruptedException e){
            //return from method

1 Like

@pspeed I am reading best practices and learned I could already be using AppStates to about 7+ classes here…

@john01dav UngrabAppState looks good! mmm, I dont know how to make it work with swing canvas, and google is not helping with: “swing canvas” “ungrab mouse”; and similars… like it could not be directly done, requiring some kind of trick, I suggest asking at stackoverflow for a workaround.
Btw, the main point I found about ungrabbing tho is that on refocusing the game (when lastUpdate gets updated again), it must re-grab only if it was grabbed before, otherwise keep ungrabbed, so it integrates smoothly.

Yeah, they’re nice. I use them for almost everything.

Tip: extend BaseAppState to get better friendlier lifecycle management of an app state’s resources.

1 Like

BaseAppState seems more elaborated than AbstractAppState (but it is still a great basic easifier), I will try it thx!

EDIT: at BaseAppState.initialize() I wonder if initialized = true; shouldnt be at the end of the method? becase some of my logic depends on initialized=false, and such methods are being called after initialized=true. I am trying to create a conditional app state (based on AbstractAppState) that will not initialize or enable unless pre-conditions are met, and it will keep trying to initialize and enable.

Also, I just noticed I forgot a loop in my app states run method. That is probably why it wasn’t working.

1 Like

Since this might also be relevant for other things:
Using Ctrl alt f1…f3 or something should give you Terminals (tty’s), without a mouse but you don’t need them anyway.

There you can Run something like: ps aux | grep MyGame.jar and then kill -9 pid

There are also some sophisticated awk one liners on the net which extract the pid out of the PS.
Usually you can also use:

kill -9 (backtick) ps aux | grep MyGame.jar (backtick)

This will however yield a few warnings since it takes the CPU time usage as pid and such