JVM crash inside JOGL

Hi,

an accomplish of mine is running my code on Windows XP and is getting a 100% repeatable JVM crash.

The crash log always shows a crash inside OpenGL32.dll /  GL4bcImpl.dispatch_glDrawArrays1 .

Stack: [0x03540000,0x03590000],  sp=0x0358f034,  free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [OpenGL32.dll+0x6a58]
C  [OpenGL32.dll+0x9ac7]
C  [jogl_desktop-37292.dll+0x8bd1]
J  jogamp.opengl.gl4.GL4bcImpl.dispatch_glDrawArrays1(IIIJ)V
J  jogamp.opengl.gl4.GL4bcImpl.glDrawArrays(III)V

This happens some minutes into the execution of the code and the same call has
been executed thousands of times before the crash.

I can't reproduce this on my Mac OS nor on my (Virtual Machine) Windows XP, the
accomplish tried the same code on Vista and it did NOT crash.

I think this is a bug as nothing I pass to the graphics system should be
able to crash it, but if I knew what sort of garbage could bring the
system down I could try to work around the problem.

So anyone any idea what sort of bad values can crash the OpenGL32.dll?

I'm also wondering if this bug is in something that JOGL supplies or
perhaps in the graphics drivers of that particular XP installation and
how can I tell?

I'm not sure I have the latest JOGL code (see below for version info)
but before I go through the trouble deploying a new JOGL version
in the problematic machine I like know if this is likely to help or not.

Could it be that newer (if available) graphics card drivers would help...

br Kusti



Below is info from my JOGL system (mind you this is on my OS X, not in the
XP that is experiencing the crash):

-----------------------------------------------------------------------------------------------------
Platform: MACOS / Mac OS X 10.8.5 (os), x86_64 (arch), GENERIC_ABI, 8 cores
MachineDescription: runtimeValidated true, littleEndian true, 32Bit false, primitive size / alignment:
  int8    1 / 1, int16   2 / 2
  int     4 / 4, long    8 / 8
  int32   4 / 4, int64   8 / 8
  float   4 / 4, double  8 / 8, ldouble 16 / 16
  pointer 8 / 8, page    4096
Platform: Java Version: 1.6.0_51, VM: Java HotSpot(TM) 64-Bit Server VM, Runtime: Java(TM) SE Runtime Environment
Platform: Java Vendor: Apple Inc., http://www.apple.com/, is JavaSE: true, AWT enabled: true
-----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------
Package: com.jogamp.common
Extension Name: com.jogamp.common
Specification Title: GlueGen Java Bindings Generator
Specification Vendor: JogAmp Community
Specification Version: 2.0
Implementation Title: GlueGen Run-Time
Implementation Vendor: JogAmp Community
Implementation Vendor ID: com.jogamp
Implementation URL: http://jogamp.org/
Implementation Version: 2.0-b52-20121101
Implementation Branch: rc
Implementation Commit: d430657cfd1f21885f3fdebebe6f0a49b1c5cd13
-----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------
Package: javax.media.opengl
Extension Name: javax.media.opengl
Specification Title: Java Bindings for OpenGL API Specification
Specification Vendor: JogAmp Community
Specification Version: 2.0
Implementation Title: Java Bindings for OpenGL Runtime Environment
Implementation Vendor: JogAmp Community
Implementation Vendor ID: com.jogamp
Implementation URL: http://jogamp.org/
Implementation Version: 2.0-b66-20121101
Implementation Branch: rc
Implementation Commit: 502847f59ef01c78a85e4ee5453a09d9b83d9a5e
-----------------------------------------------------------------------------------------------------
Default Profiles on device MacOSXGraphicsDevice[type .macosx, connection decon, unitID 0, handle 0x0, NullToolkitLock[]]
        Native
                GL4bc false
                GL4 false
                GL3bc false
                GL3 true [3.2 (Core profile, arb, FBO, hardware)]
                GL2 true [2.1 (Compatibility profile, arb, FBO, hardware)]
                GL2ES1 true
                GLES1 false
                GL2ES2 true
                GLES2 false
        Profiles
                GLProfile[GL2ES2/GL2.hw]
                GLProfile[GL2ES1/GL2.hw]
                GLProfile[GL2/GL2.hw]
                GLProfile[GL3/GL3.hw]
                GLProfile[GL2/GL2.hw]
                GLProfile[GL2GL3/GL2.hw]
                default GLProfile[GL2/GL2.hw]


Desktop Capabilities:
        none

EGL Capabilities:
        none


-----------------------------------------------------------------------------------------------------
MacOSXGraphicsDevice[type .macosx, connection decon]:
        Native
                GL4bc false
                GL4 false
                GL3bc false
                GL3 true [3.2 (Core profile, arb, FBO, hardware)]
                GL2 true [2.1 (Compatibility profile, arb, FBO, hardware)]
                GL2ES1 true
                GLES1 false
                GL2ES2 true
                GLES2 false
        Profiles
                GLProfile[GL2ES2/GL2.hw]
                GLProfile[GL2ES1/GL2.hw]
                GLProfile[GL2/GL2.hw]
                GLProfile[GL3/GL3.hw]
                GLProfile[GL2/GL2.hw]
                GLProfile[GL2GL3/GL2.hw]
                default GLProfile[GL2/GL2.hw]

Swap Interval  -1
GL Profile     GLProfile[GL2/GL2.hw]
CTX VERSION    2.1 (Compatibility profile, arb, FBO, hardware) - 2.1 NVIDIA-8.16.74 310.40.00.10f02
GL             jogamp.opengl.gl4.GL4bcImpl@7a578dfb
GL_VENDOR      NVIDIA Corporation
GL_RENDERER    NVIDIA GeForce GT 650M OpenGL Engine
GL_VERSION     2.1 NVIDIA-8.16.74 310.40.00.10f02
GLSL           true, has-compiler: true, version: 1.20
GL_EXTENSIONS  135
               GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_point_sprite GL_NV_texgen_reflection GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod
GLX_EXTENSIONS 0
               
-----------------------------------------------------------------------------------------------------
Requested: GLCaps[rgba 0x8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw], on-scr[.]]
Chosen   : GLCaps[rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL2/GL2.hw], on-scr[.]]

Hi

At first, use the very latest version of JOGL (JOGL 2.1.1). You currently use a build generated almost one year ago, tons of fixes have been added since November 2012.

This kind of crash can be caused by a driver bug or a wrong use of direct NIO buffers. Please provide a very simple test case.

Hi,

thanks for the speedy answer.

Ok, I will update my JOGL.

I don't know if I can provide a test case as I cannot reproduce this on my machine,
however here are the snippets of  the code that calls the JOGL/OpenGL32.dll that crashes:

Called from withing onDrawFrame callback:

  private  int m_Length;
        private  float[] m_Array;

        private void renderToolPathAsLine(GL gl, Vector3f zo, float z) {
                if (m_Length >= 6) {
                        int n = m_Length;
                        ByteBuffer vbb = ByteBuffer.allocateDirect(n * 4); // 4 = sizeof float
                        vbb.order(ByteOrder.nativeOrder());
                        FloatBuffer vertexBuffer = vbb.asFloatBuffer();
                        vertexBuffer.position(0);
                        vertexBuffer.put(m_Array, 0, n);
                        vertexBuffer.position(0);

                        gl.glEnableClientState(GL.GL_VERTEX_ARRAY);
                        gl.glVertexPointer(3, GL.GL_FLOAT, 0, vertexBuffer);
                        gl.glDrawArrays(GL.GL_LINE_STRIP, 0, n / 3);
                        gl.glDisableClientState(GL.GL_VERTEX_ARRAY);
                }

        }



And this is how the data gets into m_Array/m_Length,
these are called from a back ground thread:



        public void putCut(float x1, float y1, float z1, double radius) {
<SNIP>
                if (m_Length + 3 * 12 > m_Array.length) {
                        float[] nf = new float[1024 + m_Array.length + m_Array.length / 10];
                        System.arraycopy(m_Array, 0, nf, 0, m_Array.length);
                        m_Array = nf;
                }

                float[] vx = m_Array;
                int j = m_Length;

<SNIP>
                3 x 12 x  vx[j++] = ...
<SNIP>
                m_Length = j;

        }

        public void putPlan(float x, float y, float z) {

                if (m_Length + 3 > m_Array.length) {
                        float[] nf = new float[1024 + m_Array.length + m_Array.length / 10];
                        System.arraycopy(m_Array, 0, nf, 0, m_Array.length);
                        m_Array = nf;
                }
                m_Array[m_Length++] = x;
                m_Array[m_Length++] = y;
                m_Array[m_Length++] = z;
        }


Hmm ... looks like in the putPlan routine m_Length is temporarily not divisible
by 3 so that is at least wrong in my code...though it should not crash the VM.

I will fix that and try the latest JOGL release.

br Kusti

Hi

If the last parameter of glDrawArrays is incorrect, it can crash the VM even though some controls are done to minimize this risk. Your code lacks of proper synchronization, you don't use the class Buffers, you create a new direct NIO buffer each time you render your line which is horrible in terms of native memory footprint. If you succeed in reproducing this crash with a more simple example, it probably means that the problem comes from the driver. I don't see how this problem would come from JOGL itself. I see lots of people misusing direct NIO buffers... We can make some checks but at the end, if the data are wrong, JOGL can't use them to render something.

Hi

I belive you are experiencing crashes due to using deprecated fixed function pipeline glVertexPointer functionality
Automatic memory management and the fixed function pipeline have been removed by the latest
opengl 3 & 4 drivers when running without a backward compatible context.

It would be good to see the profile initialization used by your code.

If you want to use glVertexPointer make sure you use a GL2 GL2ES1 GL3bc or GL4bc context.
Please note that the backward compatible opengl contexts are not longer provided by the latest opengl drivers on many platforms.
It would also be good to see the JOGL debug output from the machine that generated the crash,
it may be possible that this machine only provide core contexts like GL3 and GL4.

To make your code forward compatible to work on future hardware that only provide opengl es 2 / opengl 3 core and later contexts
is to use explicit memory management by explicitly allocating and using VBO.

The latest JOGL 2.1.0 and later is patched to throw a runtime exception if depricated functionality is used on core contexts, instead of hitting the crash inside the driver.


2013-10-29 05:56, nyholku [via jogamp] skrev:
> Hi,
>
> thanks for the speedy answer.
>
> Ok, I will update my JOGL.
>
> I don't know if I can provide a test case as I cannot reproduce this on my machine,
> however here are the snippets of  the code that calls the JOGL/OpenGL32.dll that crashes:
...
>         private void renderToolPathAsLine(GL gl, Vector3f zo, float z) {
...
>                         gl.glEnableClientState(GL.GL_VERTEX_ARRAY);
>                         gl.glVertexPointer(3, GL.GL_FLOAT, 0, vertexBuffer);             <---- this call is passing a buffer using "automatic" memory-managment by passing a buffer, and is using the fixed function pipeline.
                                                                                                                                    this function-call is depricated and only supported using backward compatible opengl contexts
>                         gl.glDrawArrays(GL.GL_LINE_STRIP, 0, n / 3);                        <---- this call will crash on the latest opengl core contexts that require explicit memory management
                                                                                                                                   the solution is to rewrite this code to stay opengl core compatible by first binding a VBO data source before
                                                                                                                                   this call is made.



>
> br Kusti

Cheers
Xerxes

gouessej wrote

Hi

If the last parameter of glDrawArrays is incorrect, it can crash the VM even though some controls are done to minimize this risk. Your code lacks of proper synchronization, you don't use the class Buffers, you create a new direct NIO buffer each time you render your line which is horrible in terms of native memory footprint. If you succeed in reproducing this crash with a more simple example, it probably means that the problem comes from the driver. I don't see how this problem would come from JOGL itself. I see lots of people misusing direct NIO buffers... We can make some checks but at the end, if the data are wrong, JOGL can't use them to render something.

gouessej is correct here, if you use glDrawArrays on Gl2 with automatic memory management by passing a buffer java will think the buffer is eligible for garbage collection because java do not hold any reference to this buffer when the function return. If the garbage collector collects the buffer while it is in use by the opengl driver you will hit a crash inside the driver when it tries to access memory that java GC have released.

Hi gouessej and Xerxes Rånby,

thanks for the answers.

So it looks like I've got some homework to do
to learn better ways. I probably can find
out what 'class Buffer' and 'VBO data source'
are but I would not mind some pointers to
a good introductory text.

I'm more than willing to rework this code
but I have one concern. Currently my
code runs on Android without any modifications,
I have a wrapper class that forwards the
the few OpenGL calls I need to the correct
JOGL implementation class depending on the
platform. Now, if I rework my code to use
the above mentioned things I do yet know about,
will I also find those things on Android?

br Kusti

The Buffers class is documented here:
http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/nio/Buffers.html