On Thu, 6 Sep 2012,
xerxes...@gmail.com wrote:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7bccb40 (LWP 19533)]
> 0x00271e58 in ?? () from /lib/i386-linux-gnu/libc.so.6
> (gdb) bt
> #0� 0x00271e58 in ?? () from /lib/i386-linux-gnu/libc.so.6
> #1� 0x06728e27 in ?? () from /usr/lib/i386-linux-gnu/dri/i965_dri.so
> #2� 0x0673c42f in brw_upload_state ()
> �� from /usr/lib/i386-linux-gnu/dri/i965_dri.so
> #3� 0x067276f7 in brw_draw_prims ()
> �� from /usr/lib/i386-linux-gnu/dri/i965_dri.so
> #4� 0x068dd69e in ?? () from /usr/lib/i386-linux-gnu/dri/libdricore.so
> #5� 0x04861f9d in
> Java_jogamp_opengl_gl4_GL4bcImpl_dispatch_1glDrawArrays1(int0_t, __complex)
> ()
> �� from/tmp/jogamp_0000/file_cache/jln507172062703352522/jln4809309549775336484/li
> bjogl_desktop.so
> #6� 0x003c0ed3 in vmNativeCall ()
> �� from /usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386/avian-dbg/libjvm.so
> #7� 0x0032493c in vm::dynamicCall (function=0x4861f6c, arguments=0x7bcbb70,
> ��� argumentsSize=28, returnType=0) at src/x86.h:97
> #8� 0x00323fd6 in call (this=0x804bc50, function=0x4861f6c,
> ��� arguments=0x7bcbb70, types=0x7bcbb50 "\a\a\003\003\003\004\064",
> count=6,
> ��� size=28, returnType=0) at src/posix.cpp:766
> #9� 0x0037450a in invokeNativeSlow (t=0x822f5f4, method=0xae709ae8,
> ��� function=0x4861f6c) at src/compile.cpp:7536
> #10 0x0037482a in invokeNative2 (t=0x822f5f4, method=0xae709ae8)
> ��� at src/compile.cpp:7608
> #11 0x0037498c in invokeNative (t=0x822f5f4) at src/compile.cpp:7640
> #12 0x00425051 in ?? ()
I'm seeing something similar. Here's what I think the problem is:
GL2ES2.glVertexAttribPointer (which is used in RawGL2ES2demo to draw a
triangle) ultimately results in a call to
GL4bcImpl.dispatch_glVertexAttribPointer1, which is a native method
implemented as
Java_jogamp_opengl_gl4_GL4bcImpl_dispatch_1glVertexAttribPointer1__IIIZILjava_lang_Object_2IZJ
in GL4bcImpl_JNI.c, which is generated as part of the JOGL build. Here's
the generated code:
JNIEXPORT void JNICALL
Java_jogamp_opengl_gl4_GL4bcImpl_dispatch_1glVertexAttribPointer1__IIIZILjava_lang_Object_2IZJ(JNIEnv
*env, jobject _unused, jint index, jint size, jint type, jboolean
normalized, jint stride, jobject pointer, jint pointer_byte_offset,
jboolean pointer_is_nio, jlong procAddress) {
typedef void (APIENTRY*_local_PFNGLVERTEXATTRIBPOINTERPROC)(GLuint
index, GLint size, GLenum type, GLboolean normalized, GLsizei stride,
const GLvoid * pointer);
_local_PFNGLVERTEXATTRIBPOINTERPROC ptr_glVertexAttribPointer;
GLvoid * _pointer_ptr = NULL;
if ( NULL != pointer ) {
_pointer_ptr = (GLvoid *) (((char*) ( JNI_TRUE == pointer_is_nio ?
(*env)->GetDirectBufferAddress(env, pointer) :
(*env)->GetPrimitiveArrayCritical(env, pointer, NULL) ) ) +
pointer_byte_offset);
}
ptr_glVertexAttribPointer = (_local_PFNGLVERTEXATTRIBPOINTERPROC)
(intptr_t) procAddress;
assert(ptr_glVertexAttribPointer != NULL);
(* ptr_glVertexAttribPointer) ((GLuint) index, (GLint) size, (GLenum)
type, (GLboolean) normalized, (GLsizei) stride, (GLvoid *) _pointer_ptr);
if ( JNI_FALSE == pointer_is_nio && NULL != pointer ) {
(*env)->ReleasePrimitiveArrayCritical(env, pointer, _pointer_ptr,
JNI_ABORT); }
}
Yes, it's an ugly mess, but if you look closely, you can see that if
pointer_is_nio is false (and GDB is telling me it it indeed false), it
uses GetPrimitiveArrayCritical to get a direct pointer to the buffer.
That's fine, but then it releases that pointer with a call to
ReleasePrimitiveArrayCritical right after calling glVertexAttribPointer.
That can be a problem later when glDrawArrays is called, because the
native OpenGL implementation may now have a stale pointer to an object
which has been moved to a different place in memory due to a garbage
collection cycle.
Valgrind also revealed a similar bug in
Java_jogamp_opengl_x11_glx_GLX_dispatch_1glXGetProcAddress1__Ljava_lang_String_2J,
which calls ReleaseStringUTFChars to release the temporary char array
passed to glXGetProcAddress, even though Mesa holds on to that pointer and
references it in subsequent calls to glXGetProcAddress (which may just be
a bug in Mesa rather than JOGL).
Anyway, from what I can see this is a JOGL bug.