Bug 1114

Summary: Large usage of VBO's results in low native memory and JOGL using a null pointer crashing the VM
Product: [JogAmp] Jogl Reporter: Dean Cooper <dwc>
Component: openglAssignee: Sven Gothel <sgothel>
Status: RESOLVED INVALID    
Severity: major    
Priority: ---    
Version: 2.3.1   
Hardware: pc_x86_32   
OS: windows   
Type: --- SCM Refs:
Workaround: ---
Attachments: Error log file

Description Dean Cooper 2014-12-30 18:12:58 CET
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.
Comment 1 Sven Gothel 2015-03-13 07:40:35 CET
+++
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.