This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I am aware that desktop applications are no longer officially supported, but I have found a bug which freezes the system and only pressing the power button can turn off my computer, so that I can turn it on again. To demonstrate the problem I made a new application with just a combo box on it. I then asked for an event handler for the action event. I made a trivial routine to "handle" the event which I called from jComboBox1ActionPerformed. I open the combo box and choose an item which causes the action. It hits my breakpoint and that is the last thing I can do, aside from hitting the power button. The mouse will still move on the screen. Likewise I activated the System Monitor to see the CPU and memory activity. The graph will continue to graph the use of my CPU and memory. The activity is perfectly normal, indicating that nothing is caught in any loop. However even in the System Monitor I can't switch to the Process tab in order to kill Netbeans. There is no longer any response to the mouse or keyboard. The only thing which still works is the power off button. I have known about this problem for some time and usually remember to watch where I put my break points, but even I forget. Today I wanted to see if a new application with just a combo box shows the problem. It does.... This is particularly nasty when the whole computer goes down, so it would be nice to see it fixed. Otherwise I am a big fan of Netbeans, and wouldn't use anything else. Thanks, Ilan
Where did you find out that desktop applications would not be officially supported? AFAIK, it's not true at all. NetBeans fully support J2SE development. This is a known problem. See issue #93076. The system is not frozen at all, only the input does not work. To get from this state, press CRTL-ALT-F1, log in, find the process ID of the debugged application, kill -9 <PID> and ALT-F7 to go back to the GUI. Killing the debugged application should release the input. As a workaround, run your application with -Dsun.awt.disablegrab=true switch. I'll try to find out if we'll be able to detect this frozen state from debugger... if we can do something about it...
Thanks for your reply. I will try your work around. Even better I hope to remember NOT to put break points in dangerous places. I'm most happy to learn that the desktop development is still supported. It is very useful to me and I have a significant number of applications in use. I very much hope you will be able to do something about it. It is clear that it won't be easy, but it is like stepping on a land mine when it happens. Overall I am most pleased with Netbeans, and there is no software without bugs. Ilan
I've found a way how can we hack into the AWT grab state. So hopefully, we can detect this desktop lock and try to recover from that. As a result, however, there can remain un-closed popup menus on the screen. The same happens when -Dsun.awt.disablegrab=true switch is used, popup windows can be left opened when you switch between applications. But, you should be able to debug the event handlers without problems with that switch.
I'm closing this as a duplicate of issue #93076. However, I've managed to hack into X11 methods and release the window grab via debugger. Therefore it's hopefully fixed. *** This bug has been marked as a duplicate of bug 93076 ***
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/5aa81c3749e4 User: mentlicher@netbeans.org Log: #93076, #203221 Detection of paused threads of applications that holds grabbed window implemented via direct access to X serevr routines. The grab is either released, or application is resumed to prevent from frozen X server.