intermittent crashes with JOGL

Linux 32bit
JOGL 2.0 (using incremental build from 07/17/2011)
Netbeans 7.1.1
NVIDIA drivers = “version current” that came with Linux.

Program seams to work fine 20-30% of the time. Other times it crashes and I get this:

Info: XInitThreads() called for concurrent Thread support

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0xb7730f2d, pid=12378, tid=2362850160

JRE version: 6.0_31-b04

Java VM: Java HotSpot™ Server VM (20.6-b01 mixed mode linux-x86 )

Problematic frame:

C [] pthread_mutex_lock+0x1d

An error report file with more information is saved as:


If you would like to submit a bug report, please visit:

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

Result: 134
BUILD SUCCESSFUL (total time: 1 minute 46 seconds)

Any ideas what’s going on?
Thanks in advance.

If you are using VBOs, you are most likely referencing bad vertices, etc. through a glDrawElements command that has incorrect indices set up for the enabled vertex attributes. A common case is if the index is too large so it refers to a non-existent vertex, or if one set of attributes is shorter than expected.

This same code runs just fine on Windows 32.
Given your description this problem would persist across platforms if it was what you think it is wouldn’t it?

Yes and no, drivers have different behaviors when reading past the end of a VBO, and it depends where the memory lies. So even on the same OS you might have it fail or not. It’s pretty easy to check, though, you just have to make sure you’re calling glDisableClientState(x) as appropriate and that the data you’re sending as VBOs makes sense, and that indices into glDrawElements, etc. are correct.

How would I go about checking this? Sorry I am new to JOGL. I found instances of the method you were refering to:

protected void drawSideInteriors(DrawContext dc, ShapeData shapeData)
super.prepareToDrawInterior(dc, this.getActiveSideAttributes(), defaultSideAttributes);

    GL gl = dc.getGL();

    for (ExtrudedBoundaryInfo boundary : shapeData)
        if (!dc.isPickingMode() && this.mustApplyLighting(dc, this.getActiveSideAttributes()))
            gl.getGL2().glNormalPointer(GL.GL_FLOAT, 0, boundary.sideNormalBuffer.rewind());

        if (!dc.isPickingMode() && boundary.sideTextureCoords != null)
            gl.getGL2().getGL2().glTexCoordPointer(2, GL.GL_FLOAT, 0, boundary.sideTextureCoords.rewind());

        gl.getGL2().getGL2().getGL2().glVertexPointer(3, GL.GL_FLOAT, 0, boundary.sideVertexBuffer.rewind());

        for (int j = 0; j < boundary.faceCount; j++)
            if (!dc.isPickingMode() && boundary.sideTextureCoords != null)
                if (!boundary.sideTextures.get(j).bind(dc))


            boundary.sideIndices.position(4 * j);
            boundary.sideIndices.limit(4 * (j + 1));
            gl.glDrawElements(GL.GL_TRIANGLE_STRIP, 4, GL.GL_UNSIGNED_INT, boundary.sideIndices);

Does anything here look suspect? How do you go about checking what you mentioned?

Also in case it is relevant, I get the following warning right before the crash message in the OP:

WARNING [org.openide.filesystems.Ordering]: Found same position 100 for both Toolbars/File/PolygonAction.shadow and Toolbars/File/RectangleAction.shadow

This warning persists though even during the 20-30% of the cases when the program works.

The only suspect thing I can see is that you’re not calling glEnableClientState(GL_NORMAL_ARRAY) and glDisableClientState(GL_NORMAL_ARRAY), even though you only set the glNormalPointer during certain conditions.

I also don’t see where you call glEnableClientState(GL_VERTEX_ARRAY).

You want to look for these types of inconsistencies anywhere you use the glVertexPointer code to perform rendering. Another draw method to look for is glDrawArrays(), which you might be using.

I’d like to exhaust other solutions before jumping into editing code I didn’t write especially given the size of this project.
You mention the reason this code might be working in Windows but works only part of the time in Linux is because of the way
drivers (assume graphics card drivers?) interact with VBOs. Could it be possible I am not using the proper/best

It is possible, you may want to try creating a very rudimentary demo, too.


lhkbob is right, please try to provide a small test case. I assume you try to use WorldWind with JOGL 2.0. Some people already succeeded in doing it, maybe there is something wrong in your code.

Anyway, please use a more recent version of JOGL 2.0. If you have a real problem with a real bug in JOGL, we won’t be able to help you if you don’t use the latest build.

Can you please tell me why newt.all and nativewindow.all are missing in all post Sept/Oct 2011 builds?
Should I use newt.core or any other and in atomic folder to replace them if I want to use latest stuff?

Most JOGL tutorials require using 4 files: jogl.all, gluren-rt, newt.all and nativewindow.all. Last 2 are missing in newer builds.

Use jogl.all.jar and gluegen-rt.jar or all atomic JARs. jogl.all.jar contains NEWT stuffs too.


Now I am basically back to where I was in the OP except with the latest (04/22/2012) JOGL build. (still works, but not every time and gives the same error).
I am currently getting the following blocks of warnings in case this sheds some light on this issue:

Warning: com.jogamp.nativewindow.swt.SWTAccessor cannot access
Warning: com.jogamp.nativewindow.swt.SWTAccessor cannot access org.eclipse.swt.widgets.Control
Warning: com.jogamp.nativewindow.swt.SWTAccessor$1 cannot access org.eclipse.swt.widgets.Control
Warning: com.jogamp.nativewindow.swt.SWTAccessor$2 cannot access
Warning: com.jogamp.nativewindow.swt.SWTAccessor$2 cannot access org.eclipse.swt.widgets.Control
Warning: com.jogamp.nativewindow.swt.SWTAccessor$3 cannot access
Warning: com.jogamp.nativewindow.swt.SWTAccessor$3 cannot access org.eclipse.swt.widgets.Control
Warning: com.jogamp.opengl.swt.GLCanvas cannot access
Warning: com.jogamp.opengl.swt.GLCanvas cannot access

and also:

Warning: cannot access com.sun.codemodel.JArrayClass$1
Warning:$1 cannot access com.sun.codemodel.JArrayClass$1
Warning:$1 cannot access com.sun.codemodel.JCodeModel$1
Warning:$JReferencedClass cannot access com.sun.codemodel.JCodeModel$1
Warning: cannot access com.sun.codemodel.JNestedClass
Warning: cannot access com.sun.codemodel.JExpr$3
Warning:$3 cannot access com.sun.codemodel.JExpr$3
Warning: cannot access com.sun.codemodel.JNestedClass
Warning: cannot access com.sun.codemodel.JNullType$1
Warning:$1 cannot access com.sun.codemodel.JNullType$1

but I was reading that the 2nd block’s warnings are not significant.

Any thoughts?

I didn’t know you use the experimental SWT heavyweight canvas. Please report your problem on the official forum of JogAmp, you will get more replies.

I downloaded a swt.jar and added it to the project and those warnings went away, but the problem didn’t :frowning:
Now all I get are some warnings, been ignoring them for now.