United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7160609 [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)
JDK-7160609 : [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)

Details
Type:
Bug
Submit Date:
2012-04-11
Status:
Closed
Updated Date:
2013-06-13
Project Name:
JDK
Resolved Date:
2012-09-01
Component:
client-libs
OS:
os_x
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u4
Fixed Versions:
7u40 (b08)

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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
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.
                                     
2012-04-12
EVALUATION

We must reasonably cap the maximum size allowed for a top-level window.
                                     
2012-04-12
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.
                                     
2012-04-12
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).
                                     
2012-04-12
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
                                     
2012-04-12
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.
                                     
2012-08-17
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.
                                     
2012-08-17
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.
                                     
2012-08-20
/test: test/java/awt/Frame/HugeFrame/HugeFrame.java
                                     
2012-12-06
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/ef52ce0ad900
User:  coffeys
Date:  2012-12-20 17:35:22 +0000

                                     
2012-12-20
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/ef52ce0ad900
User:  lana
Date:  2012-12-28 18:30:44 +0000

                                     
2012-12-28
Verified in 7u40 b25 with the regtest
                                     
2013-06-13



Hardware and Software, Engineered to Work Together