JVM Crash java 1.6.0_12, JOGL sun.java2d.d3d=false OR sun.java2d.noddraw=true

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

JVM Crash java 1.6.0_12, JOGL sun.java2d.d3d=false OR sun.java2d.noddraw=true

ichiban
Experiencing a JVM crash when using java 1.6.0_12 with either sun.java2d.d3d=false AND/OR sun.java2d.noddraw=true.

A post regarding this issue exists on http://www.java-gaming.org, it was recommended that I go here as well.

It works just fine when I do one of the following:

-get rid of BOTH sun.java2d.d3d=false OR sun.java2d.noddraw=true
-switch to java 1.6.0_22 (have not tested it with other versions)

JOGL documentation specifies that in order to avoid issues, you have to set sun.java2d.d3d=false.  However in my case that crashes with 1.6.0_12, and has no relevant impact on 1.6.0.22.

Currently, my users have to stay in java 1.6.0_12, the usage of OpenGL is a small part of the application.

My machine is Windows7, however this was experienced accross Windows XP and accross various graphics cards as well.

I've debugged my application and found that the crash happens at GLProfile.initSingleton().  For this function I pass in false, since openGL will not be used every time by the application.  My application does a lot of Java2D drawing.

Further debugging shows that the actual crash happens at line 1266 of GLProfile.class:


boolean addedAnyProfile = initProfilesForDevice(defaultDesktopDevice) ||
initProfilesForDevice(defaultEGLDevice);



if you look at the code for initProfilesForDevice() this is what it is:
    /**
     * @param device the device for which profiles shall be initialized
     * @return true if any profile for the device exists, otherwise false
     */
    private static synchronized boolean initProfilesForDevice(AbstractGraphicsDevice device) {
        if(null == device) {
            return false;
        }
        GLDrawableFactory factory = GLDrawableFactory.getFactoryImpl(device);
        factory.enterThreadCriticalZone();
        try {
            return initProfilesForDeviceImpl(device);
        } finally {
            factory.leaveThreadCriticalZone();
        }
    }


The weird thing is that if I step over this using the debugger then I disconnect from the debugger letting the application continue, it does not crash.  However if i let the application continue before this function, it crashes.  

What is this thread critical zone for?  If I am able to debug through it and the application works fine, this probably means that there is some thread miscommunication that when ran fast it is not synchronized or something...