JDK-8113911 : Mac: Using close button on window gives -[GlassWindow dealloc] message
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2011-06-30
  • Updated: 2015-06-16
  • Resolved: 2011-10-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7-poolResolved
Related Reports
Relates :  
Description
If you close a javafx application with the window close button (if you dont get a java crash) you will get:

Java has been detached already, but someone is still trying to use it at -[GlassWindow dealloc]:/HUDSON/workspace/presidio/label/macosx-universal-14/glass/glass-mat-lib-macosx/src/com/sun/mat/ui/GlassWindow.m:362

Steps:
Run BrickBreaker from sdk/apps dir with java -jar BrickBreaker.jar
Use the the demo's window close button to close the demo and you will get the error
Comments
Should be fixed by Rt-17345/RT-17213
25-10-2011

With a workaround introduced with RT-15601 this shouldn't be reproducible. A real fix for this issue (which may be risky) should go in Presido Updates.
12-08-2011

The main justification for pushing this fix out of beta is that the reward is low - removing a spewage, but risk is high - I was getting a crash with this fix on exit in DigitalClock applet.
11-08-2011

I tried implementing it, but I was getting a new crash on DigitalClock app on quit. I tried improving on the fix, but I was still getting the crash. We'll need to take a second look later, or wait for the Glass app life cycle feature to go in.
09-08-2011

Thanks Steve, will take a took and evaluate your solution. It still does not protect from client trying to use Glass after it's shutdown, but the detach operation should not be causing issues itself as you point out.
12-07-2011

The idea is to defer the detaching of the JVM until after deferred messages have run. I left in various prints etc. to show that the JVM is actually getting detached.
11-07-2011

diff -r 3cc1368d3ae4 glass-mat-lib-macosx/src/com/sun/mat/ui/GlassApplication.m --- a/glass-mat-lib-macosx/src/com/sun/mat/ui/GlassApplication.m Wed Jul 06 12:27:01 2011 +0100 +++ b/glass-mat-lib-macosx/src/com/sun/mat/ui/GlassApplication.m Mon Jul 11 17:39:35 2011 -0400 @@ -270,6 +270,20 @@ GLASS_CHECK_EXCEPTION(env); } +- (void) detachJVM: (id)selector { + NSLog(@"*** DETATCH VM"); + + GLASS_CHECK_EXCEPTION(jEnv); + + jint error = (*jVM)->DetachCurrentThread(jVM); + if (error < 0) + { + NSLog(@"Unable to detach from JVM. Error code: %d\n", (int)error); + } + + jEnv = NULL; +} + - (void)runLoop:(id)selector { LOG("GlassApplication:runLoop"); @@ -329,16 +343,19 @@ // enter runloop, this will not return until terminated [NSApp run]; + + [glassApp performSelectorOnMainThread:@selector(detachJVM:) withObject:NULL waitUntilDone:NO]; + - GLASS_CHECK_EXCEPTION(jEnv); + // GLASS_CHECK_EXCEPTION(jEnv); - jint error = (*jVM)->DetachCurrentThread(jVM); - if (error < 0) - { - NSLog(@"Unable to detach from JVM. Error code: %d\n", (int)error); - } + //jint error = (*jVM)->DetachCurrentThread(jVM); + // if (error < 0) + // { + // NSLog(@"Unable to detach from JVM. Error code: %d\n", (int)error); + // } - jEnv = NULL; + // jEnv = NULL; } else // event loop is not started {
11-07-2011

I get this ever time I close a window on the Mac. I'm reopening this issue and asking for it to be fixed independent of fixing the lifecycle issue. I have a patch.
11-07-2011

This is another duplicate of life cycle issue - RT-14271
06-07-2011