JVM crash on Solaris

I’m experiencing the following JVM crash on a Solaris 9 box using jogl 1.1b10 and jdk 1.5.0_02.

C  [libX11.so.4+0x387e4]  XVisualIDFromVisual+0x4
C  [libjogl.so+0x5eb84]  Java_net_java_games_jogl_impl_JAWT_1DrawingSurface_GetDrawingSurfaceInfo0+0x7c
net.java.games.jogl.impl.JAWT_DrawingSurface.GetDrawingSurfaceInfo0(Ljava/nio/Buffer;)Ljava/nio/ByteBuffer;+0
net.java.games.jogl.impl.JAWT_DrawingSurface.GetDrawingSurfaceInfo0(Ljava/nio/Buffer;)Ljava/nio/ByteBuffer;+0
net.java.games.jogl.impl.JAWT_DrawingSurface.GetDrawingSurfaceInfo()Lnet/java/games/jogl/impl/JAWT_DrawingSurfaceInfo;+5
net.java.games.jogl.impl.x11.X11OnscreenGLContext.lockSurface()Z+104
net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(Ljava/lang/Runnable;)Z+1
net.java.games.jogl.impl.GLContext.invokeGL(Ljava/lang/Runnable;ZLjava/lang/Runnable;)V+246
net.java.games.jogl.GLCanvas$2.run()V+19
java.awt.event.InvocationEvent.dispatch()V+47
java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
java.awt.EventDispatchThread.pumpOneEventForHierarchy(ILjava/awt/Component;)Z+200
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+26
java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
java.awt.EventDispatchThread.run()V+9

The code that is causing the crash is the setSize call in the following bit of code

JFrame f = new JFrame();
GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas( new GLCapabilities() );
final GLDrawableHolder drawableHolder = new GLDrawableHolder( canvas, new GLDrawableDecorator( canvas ) );

Component component = drawableHolder.getComponent();
GLDrawable drawable = drawableHolder.getGLDrawable();

Listener listener = new Listener();
drawable.addGLEventListener( listener );
component.addMouseListener( listener );
component.addMouseMotionListener( listener );

component.setSize( 600, 600 );

Container pane = f.getContentPane();
pane.setLayout( new BorderLayout() );
pane.add( component );

f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
f.pack();
f.invalidate();
f.setVisible( true );

I’ve reduced my code to a little program that reproduces the error (http://pepijn.fab4.be/jogl_bug.zip). This crash does not happen every time I launch the application, so I suspect there’s a race condition somewhere.

I tried your test case on a Solaris 9 box (probably with no hardware-accelerated 3D graphics, though) and wasn’t able to reproduce a crash in about 20 times of launching the application.

In my understanding the setSize() call shouldn’t cause any operations on the OpenGL context because the component hasn’t been made visible yet. Can you run with -Djogl.debug specified on the command line and post the output?

Ken, thanks for the help. I’m one of pepijnve’s coworkers, and since he’s not in the office I’ll follow up on this. Here’s the output with -Djogl.debug:

In the case of a crash:

Available 0: null
Available 1: null
Available 2: null
Available 3: null
Available 4: null
Available 5: null
Available 6: null
Available 7: null
Available 8: null
Available 9: null
Available 10: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 11: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 12: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 13: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 14: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 15: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Choosing window system's recommended choice of 14
GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
GLContext.setRealized(true) for context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# (SNIP - see pepijnve's post for the rest)

When it runs:

Available 0: null
Available 1: null
Available 2: null
Available 3: null
Available 4: null
Available 5: null
Available 6: null
Available 7: null
Available 8: null
Available 9: null
Available 10: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 11: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 12: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 13: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 14: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Available 15: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
Choosing window system's recommended choice of 14
GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 28, StencilBits: 4, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ]
GLContext.setRealized(true) for context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c
!!! Created GL context for net.java.games.jogl.impl.x11.X11OnscreenGLContext
!!! Initializing GLU extension address table
!!! Initializing OpenGL extension address table
!!! GLX version: major 1, minor 4
Init
Making context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c current
Reshape
Reshape
Freeing context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c
Making context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c current
Display
Freeing context net.java.games.jogl.impl.x11.X11OnscreenGLContext@a56a7c

Hope this helps…

This looks similar to crashes seen in early JOGL releases on X11 where the JAWT is not robust when a component is passed in that hasn’t been realized yet. However, the code added to GLCanvas.addNotify() and removeNotify() in recent releases solved the problem in all of the cases I’ve seen so far.

I’m not sure at this point that the setSize() call is the culprit. As far as I can see, that doesn’t cause any OpenGL work to be done. Try putting in some printing code along with the output of -Djogl.debug and see if you can see which operation on your widget hierarchy is causing the crash. The stack trace in the message above is from the AWT event queue thread, but what is more interesting is which operation is being run on the main thread. I’ve run the test more on my machine (without reproducing the crash) and it looks like the call to frame.pack() is what’s causing GLCanvas.addNotify() to be called, so the earlier setSize() is being deferred.