JDK-8124349 : Mac: JVM crashes when screen resolution is changed
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-03-05
  • Updated: 2015-06-17
  • Resolved: 2013-03-12
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 8
8Fixed
Related Reports
Relates :  
JDK-8118342 - JVM crashes after display mode is changed from LoDPI to HiDPI (FX app with ImageView)
Description
Steps to reproduce:
1. Run a JavaFX app. The crash is reproducible with any app, however it is always seen with the BricksBreaker from ga-samples.
2. Open System Preferences -> Displays on the same desktop as the running app.
3. Change the screen resolution, the app will crash.

The crash logs are attached.

According to the log it looks like the crash is happening in the code related to vsync, which is located in the GlassTimer and GlassScreen.initIDs
Comments
Steve's fix is good as it fixes the problem, however there is an additional issue: when new threads are created on Screen resolution change old ones are never stopped and detached. So this issue needs a more complicated fix.
06-03-2013
I see. Either way is fine with me. Perhaps Steve wants to fix it?
05-03-2013
Graphics team maintains the vsync-based timer. But since the code is in the Glass directory, OK, let this issue be listed under the Glass component in JIRA. Assigning to Petr, but he may reassign to a Graphics engineer if he doesn't have resources to fix this himself.
05-03-2013
Seems like this is a glass bug given the analysis, so the component should probably be changed back to Glass.
05-03-2013
+1
05-03-2013
The "if (1) ..." is obviously bogus. Since attaching to a thread that is already attached is not an error, we should probably just do this on every call in rather than attempting to detect a different thread.
05-03-2013
I think the crash happens because changing the display resolution creates a new thread for CVDisplayLink and we call into Java with a stale JNIEnv. The following patch fixes the problem: diff --git a/glass/glass-lib-macosx/src/GlassTimer.m b/glass/glass-lib-macosx/src/GlassTimer.m --- a/glass/glass-lib-macosx/src/GlassTimer.m +++ b/glass/glass-lib-macosx/src/GlassTimer.m @@ -119,7 +119,7 @@ { GlassTimer *timer = (GlassTimer*)displayLinkContext; - if (timer->_env == NULL) + if (1) //timer->_env == NULL) { jint error = (*MAIN_JVM)->AttachCurrentThreadAsDaemon(MAIN_JVM, (void **)&timer->_env, NULL); if (error != 0)
05-03-2013
This must be a duplicate of RT-28548, or it's a very similar issue anyway, since the crash involves the CVOutputCallback (the vsync-based timer implementation in Glass).
05-03-2013