Created attachment 681 [details] Error log file We have a large application built on top of NASA WorldWind, that uses lots of VBO's. When the app is run in 32-bit mode, native memory gets very low until it hits a point where JOGL apparently has an allocation error but blindly uses the NULL pointer, which then leads to an Access Violation exception which crashes the VM. Our work around is to limit the number of VBO's we create at any give time. They are created on every frame and old ones can safely be disposed of. We are using JOGL 2.0_rc11 and Java 7.0_60-b19.I've attached one of our error logs.
+++ public void glDrawElements(int mode, int count, int type, long indices_buffer_offset) { checkElementVBOBound(true); final long __addr_ = _pat._addressof_glDrawElements; if (__addr_ == 0) { throw new GLException(String.format("Method \"%s\" not available", "glDrawElements")); } dispatch_glDrawElements1(mode, count, type, indices_buffer_offset, __addr_); } Java_jogamp_opengl_gl4_GL4bcImpl_dispatch_1glDrawElements1__IIIJJ(JNIEnv *env, jobject _unused, jint mode, jint count, jint type, jlong indices, jlong procAddress) ++ ^^ you care calling through the above, then the GL driver fails. Hence the VBO buffer is not valid, i.e. the allocation method may have returned 'null' itself? This should be the expected behavior if you are running out of memory. glBufferData will throw an GLException if a GL error occurred, see: <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GL.html#glBufferData%28int,%20long,%20java.nio.Buffer,%20int%29> Here it seems this is not the case, in your low memory situation. This is a known issue w/ NV drivers (I experienced on OSX for example, 1-2 years ago). Nothing JOGL can do about here. Please note that the behavior of 'glMapBufferRange' and our 'mapBufferRange' is similar, but the 'null' return (ref. memory mapped GPU -> CPU) needs to be managed by the user): <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLBase.html#mapBufferRange%28int,%20long,%20long,%20int%29> Memory mapping might be a better API, probably detecting this issue? .. in short: Not a JOGL issue.