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

OpenGL Development JOGL Development
#1

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

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 not 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.

Part of the hs_err_pidXXXX.log, if requested I will share the whole file:

# # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x634f0000, pid=12240, tid=15188 # # Java VM: Java HotSpot(TM) Client VM (11.2-b01 mixed mode windows-x86) # Problematic frame: # C 0x634f0000 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #

--------------- T H R E A D ---------------

Current thread (0x63673000): JavaThread “AWT-EventQueue-0-SharedResourceRunner” daemon [_thread_in_native, id=15188, stack(0x66030000,0x66130000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x634f0000

Registers:
EAX=0x00200310, EBX=0x63673100, ECX=0x00000000, EDX=0x3b01020d
ESP=0x6612f6f8, EBP=0x6612f738, ESI=0x00000000, EDI=0x00000004
EIP=0x634f0000, EFLAGS=0x00010286

Top of Stack: (sp=0x6612f6f8)
0x6612f6f8: 616abaa6 3b01020d 00000000 00000000
0x6612f708: 6612f7f8 63673114 63673000 00000006
0x6612f718: 00000001 00000000 00000001 00000000
0x6612f728: 00000000 00000000 00000000 01007478
0x6612f738: 6612f778 5daac606 3b01020d 00000000
0x6612f748: 6612f710 00000000 3b01020d 00000000
0x6612f758: 616a7470 56c1047c 00000008 63673000
0x6612f768: 0751f800 0751f800 0751f800 63673000

Instructions: (pc=0x634f0000)
0x634efff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x634f0000:
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xc0000005]

Stack: [0x66030000,0x66130000], sp=0x6612f6f8, free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x634f0000
C [jogl_desktop.dll+0x3c606]
j jogamp.opengl.windows.wgl.WGLExtImpl.dispatch_wglCreateContextAttribsARB1(JJLjava/lang/Object;IZJ)J+0
j jogamp.opengl.windows.wgl.WGLExtImpl.wglCreateContextAttribsARB(JJ[II)J+98
j jogamp.opengl.windows.wgl.WindowsWGLContext.createContextARBImpl(JZIII)J+323
j jogamp.opengl.GLContextImpl.createContextARBVersions(JZIIIII[I[I)J+146
j jogamp.opengl.GLContextImpl.createContextARBMapVersionsAvailable(IZ)V+123
j jogamp.opengl.GLContextImpl.mapGLVersions(Ljavax/media/nativewindow/AbstractGraphicsDevice;)V+9
j jogamp.opengl.GLContextImpl.createContextARB(JZ[I[I[I)J+121
j jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl()Z+382
j jogamp.opengl.GLContextImpl.makeCurrentLocking()I+126
j jogamp.opengl.GLContextImpl.makeCurrent()I+106
j jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory$SharedResourceImplementation.createSharedResource(Ljava/lang/String;)Ljogamp/opengl/SharedResourceRunner$Resource;+226
j jogamp.opengl.SharedResourceRunner.run()V+213
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j jogamp.opengl.windows.wgl.WGLExtImpl.dispatch_wglCreateContextAttribsARB1(JJLjava/lang/Object;IZJ)J+0
j jogamp.opengl.windows.wgl.WGLExtImpl.wglCreateContextAttribsARB(JJ[II)J+98
j jogamp.opengl.windows.wgl.WindowsWGLContext.createContextARBImpl(JZIII)J+323
j jogamp.opengl.GLContextImpl.createContextARBVersions(JZIIIII[I[I)J+146
j jogamp.opengl.GLContextImpl.createContextARBMapVersionsAvailable(IZ)V+123
j jogamp.opengl.GLContextImpl.mapGLVersions(Ljavax/media/nativewindow/AbstractGraphicsDevice;)V+9
j jogamp.opengl.GLContextImpl.createContextARB(JZ[I[I[I)J+121
j jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl()Z+382
j jogamp.opengl.GLContextImpl.makeCurrentLocking()I+126
j jogamp.opengl.GLContextImpl.makeCurrent()I+106
j jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory$SharedResourceImplementation.createSharedResource(Ljava/lang/String;)Ljogamp/opengl/SharedResourceRunner$Resource;+226
j jogamp.opengl.SharedResourceRunner.run()V+213
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
#2

Hi!

Thank you for the report. However, we cannot provide fixes for bugs of the JVM already fixed in later versions, do you see what I mean? A small test case to reproduce your bug would be useful to see whether it is really a bug of JOGL.

#3

Hi, thanks for your reply, yeah that is reasonable, was not looking for a specific bug fix within JOGL, just wanted to post this out there to see if anybody else was experiencing a similar issue and for a possible work around.

I tried to write a simple program to reproduce it, however it does not crash even with the same parameters (java 1.6.0_12, sun.java.2d.d3d=false and sun.java2d.noddraw=true).

Afterwards, I 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…

#4

Please speak about that to Sven as you have some precise pieces of information now. Thanks for debugging :slight_smile: Go to http://jogamp.org