Bug 1114 - Large usage of VBO's results in low native memory and JOGL using a null pointer crashing the VM
Summary: Large usage of VBO's results in low native memory and JOGL using a null point...
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2
Hardware: pc_x86_32 windows
: --- major
Assignee: Sven Gothel
Depends on:
Reported: 2014-12-30 18:12 CET by Dean Cooper
Modified: 2015-03-13 07:40 CET (History)
0 users

See Also:
Type: ---
SCM Refs:
Workaround: ---

Error log file (42.86 KB, text/plain)
2014-12-30 18:12 CET, Dean Cooper

Note You need to log in before you can comment on or make changes to this bug.
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)  {

    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:

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):

Memory mapping might be a better API, probably detecting this issue?

.. in short: Not a JOGL issue.