JDK-7160609 : [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-04-11
  • Updated: 2013-09-06
  • Resolved: 2012-09-01
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 JDK 8
7u10Fixed 8Fixed
Related Reports
Relates :  
JDK-8010999 - [macosx] a constrain of the top level window should be improved
Relates :  
JDK-7200762 - [macosx] Stuck in sun.java2d.opengl.CGLGraphicsConfig.getMaxTextureSize(Native Method)
Relates :  
JDK-7197298 - [macosx] Stuck in sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
Description
JDK crash during using NetBeans. In NB, hit "view data" in slowness reporter dialog.
Attaching log with crash, NetBeans log, content of "Report to apple" dialog.


# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000020000675a, pid=13021, tid=140735276149088
#
# JRE version: 7.0_04-b19
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b20 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [GeForceGLDriver+0x675a]  gldAttachDrawable+0x941
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Applications/NetBeans/NetBeans Dev 201204100400.app/Contents/Resources/NetBeans/bin/hs_err_pid13021.log
Phoning home... 
Using server: 10.161.186.18, port 4711
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Comments
Verified in 7u40 b25 with the regtest
13-06-2013
/test: test/java/awt/Frame/HugeFrame/HugeFrame.java
06-12-2012
EVALUATION MS Windows limits the maximum size of a window to the maximum visible area of all screens present on a system. Therefore, it makes sense to introduce the same limitation on the Mac platform as well, even though the OS won't do that automatically. In most practical cases, the total screen size must be OK for OpenGL to create a texture of that size, and thus avoid the crash/exception.
20-08-2012
EVALUATION On the other hand, Mac will constrain windows' sizes upon first displaying so that they fit the screen. Perhaps it makes sense to use the screen size as a limiter for a window size.
17-08-2012
EVALUATION On my system GL_MAX_TEXTURE_SIZE returns 8192. If only one dimension of a frame gets constrained to this size, but another one is a reasonable value (say, the resulting dimensions are (300, 8192)), then everything is fine with the constrian applied. However, if both dimensions are insane and get constrained to (8192, 8192), OpenGL code still fails to create a texture. (8191, 8191) fails as well. There's a relevant forum post: http://compgroups.net/comp.graphics.api.opengl/texture-size-gl_max_texture_size/179511 which suggests to "try" creating smaller textures until it succeeds, but I'm not an export in GL and not sure how relevant that is.
17-08-2012
EVALUATION I've added a hot fix in the Suggested Fix section that should resolve the issue. This fix adds a hard-coded constraint for the maximum size of a window of 8000 pixels. This fix is safe and may be integrated in 7u4 if need arises. For 7u6 this fix should take into account the maximum texture size that the OpenGL is able to create on this system (GL_MAX_TEXTURE_SIZE).
12-04-2012
SUGGESTED FIX diff -r 0b287839e567 src/macosx/classes/sun/lwawt/LWWindowPeer.java --- a/src/macosx/classes/sun/lwawt/LWWindowPeer.java +++ b/src/macosx/classes/sun/lwawt/LWWindowPeer.java @@ -347,6 +347,12 @@ if (h < MINIMUM_HEIGHT) { h = MINIMUM_HEIGHT; } + if (w > 8000) { + w = 8000; + } + if (h > 8000) { + h=8000; + } // Don't post ComponentMoved/Resized and Paint events // until we've got a notification from the delegate
12-04-2012
EVALUATION Even if we constrain the size for a native setBounds request (in the AWTWindow -constrainSize: ), we'll still get an OutOfMemory exception as follows: Exception in thread "main" java.lang.OutOfMemoryError: can't create offscreen surface at sun.java2d.opengl.OGLSurfaceData.initSurfaceNow(OGLSurfaceData.java:298) at sun.java2d.opengl.OGLSurfaceData.access$000(OGLSurfaceData.java:98) at sun.java2d.opengl.OGLSurfaceData$1.run(OGLSurfaceData.java:324) at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:234) Looks like 2D code tries to create a surface based on the size of the window as requested by user, not the real, native window size.
12-04-2012
EVALUATION We must reasonably cap the maximum size allowed for a top-level window.
12-04-2012
EVALUATION A window hierarchy listed in comment section seems to be a cause of the problem. Note that for some reasons, the NbDialog instance has too big height. There is simplified testcase, which demonstrates the same crash: public class HugeWindow { public static void main(String[] args) { JFrame f = new JFrame("Huge"); f.setBounds(10, 10, 300, 500000); f.setVisible(true); } } Note that this test works fine on other platforms (and on macosx with apple jdk) because we limit the real height of the window. So, I am re-dispatching this issue to AWT team for further investigation.
12-04-2012