 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / September 2005Simple Swing-application crashes JVM 1.5 and parts of Windows
I am using Java 1.5 and have written a Swing-application, which will "crash" when its main window is closed. Under Windows 98 the JVM does not terminate in this case and even CTRL-ALT-DEL will not bring up the task manager anymore to terminate the JVM process, otherwise Windows can still be used. Two other process control programs can not terminate the JVM -- only a certain command-line "kill" program I tried eventually was able to do this. I was able to track down the problem to a very simple program: public class Main { public static void main( final java.lang.String[] _ ) { // javax.swing.JFrame.setDefaultLookAndFeelDecorated( true ); javax.swing.JFrame frame = new javax.swing.JFrame(); frame.setDefaultCloseOperation( javax.swing.JFrame.EXIT_ON_CLOSE ); frame.pack(); frame.setVisible( true ); }} The crash behavior will occur if the two characters "//" are removed from the above program. Is anything known about such behavior? >public class Main >{ public static void main( final java.lang.String[] _ ) [quoted text clipped - 3 lines] > frame.pack(); frame.setVisible( true ); }} > The crash behavior will occur if the two characters "//" This might have been a coincidence. The error now occurs even with the "//" included. I assume that the code is correct and it might have to do something with my software environment. > I am using Java 1.5 and have written a Swing-application, > which will "crash" when its main window is closed. Under [quoted text clipped - 4 lines] > JVM -- only a certain command-line "kill" program I tried > eventually was able to do this. Usually these types of problems are caused by video driver bugs, and usually they are DirectDraw-related. Try running with -Dsun.java2d.noddraw flag. If that fixes the problem, see if there is an updated video driver available for your system. >Usually these types of problems are caused by video driver >bugs, and usually they are DirectDraw-related. Try running >with -Dsun.java2d.noddraw flag. If that fixes the problem, >see if there is an updated video driver available for your >system. Thank you! This makes sense to me, because I already know that I have such driver problems. I am using a somewhat historic graphic card. It is good to know that my code is not the cause. My original code was even more "correct" than the one posted. Instead of frame.pack(); frame.setVisible( true ); I used frame.pack(); javax.swing.SwingUtilities.invokeLater ( new java.lang.Runnable() { public void run(){ frame.setVisible( true ); }}); because according to the specification "frame.pack" would start the event-dispatching thread (EDT), so it should not be allowed for the main thread to send "setVisible( true )" then. But everyone seems to do this, IIRC even Sun tutorials. I never saw any other source for the second code example, so I hope that I have not overlooked a reason not to use this. >>with -Dsun.java2d.noddraw flag. If that fixes the problem, > Thank you! This makes sense to me, because I already know that But actually this did not help. It now seems to me that the Windows-Programm "AllChars" has to do with it. Several times I have now observed that an "invalid page" is reported in "Kernel32.DLL" if the Swing-Program was terminated while "AllChars" was activated, but that this message is not reported when "AllChars" does not run at the time the Swing-Application was started. "AllChars" allows one to enter characters which are not available from the keyboard or to reply macros. An AllChars-DLL is loaded with a all processes started while "AllChars" is active. >>>with -Dsun.java2d.noddraw flag. If that fixes the problem, >> Thank you! This makes sense to me, because I already know that [quoted text clipped - 7 lines] > reported when "AllChars" does not run at the time the > Swing-Application was started. Try a different version of Java. >Try a different version of Java. I now have written a wrapper to start the JVM, while AllChars is deactivated. A batch file contains code similar to: perl terminate_AllChars.pl java SwingApplication AllChars.exe > My original code was even more "correct" than the one posted. > [quoted text clipped - 16 lines] > I never saw any other source for the second code example, so > I hope that I have not overlooked a reason not to use this. Yes, you should always do all gui operations on the EDT to avoid unexpected exceptions at startup. And any problems are likely to be timing-related, so just because code that doesn't do this works on your system 999 times doesn't mean it won't fail the 1000th time or every time on another system. When the jvm or your system crashes though, then it can not be the fault of your Java code. It's either a Java bug or a system problem. >frame.pack(); >javax.swing.SwingUtilities.invokeLater [quoted text clipped - 4 lines] > start the event-dispatching thread (EDT), so it should not be > allowed for the main thread to send "setVisible( true )" then. there are a few methods that are thread safe that don't need invokeLater There are a few exceptions to this general rule, most notably it is safe to call repaint and revalidate, JTextComponent.setText and JTextArea.append from any thread. I vaguely recall reading setVisible is also safe, but I can't find the reference.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >public class Main >{ public static void main( final java.lang.String[] _ ) [quoted text clipped - 7 lines] > > Is anything known about such behavior? Let's gradually get rid of some of the quirky things to see just what is causing the trouble. 1. take the final off the arg to main. 2. write that in standard way String[] args, without using _ 3. put something in your frame. even just a label. That basic code must exist in thousands of programs that are working fine. When you have the cause nailed, post the bug at Sun. The link is at http://mindprod.com/jgloss/bugs.html You are doing a great public service tracking this down to so tight an SSCCE SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.