Hello,
When I try to use shaders with opengl, my VM crashes. This is my code: try { shaderProgram = gl.glCreateProgramObjectARB(); vertexShaderObject = gl.glCreateShaderObjectARB(GL2.GL_VERTEX_SHADER); fragmentShaderObject = gl.glCreateShaderObjectARB(GL2.GL_FRAGMENT_SHADER); try { String vp = loadFile("test_vertex.vp"); gl.glShaderSourceARB(vertexShaderObject, 1, new String[] { vp }, new int[] { vp.length() }, 0); String fp = loadFile("test_fragment.fp"); gl.glShaderSourceARB(fragmentShaderObject, 1, new String[] { fp }, new int[] { fp.length() }, 0); } catch (IOException e) { System.err.println("Error while Loading shader code"); e.printStackTrace(); System.exit(1); } gl.glCompileShaderARB(vertexShaderObject); gl.glCompileShaderARB(fragmentShaderObject); gl.glAttachObjectARB(shaderProgram, vertexShaderObject); gl.glAttachObjectARB(shaderProgram, fragmentShaderObject); gl.glLinkProgramARB(shaderProgram); gl.glUseProgramObjectARB(shaderProgram); } finally { if (vertexShaderObject != 0) { gl.glDeleteShader(vertexShaderObject); } if (fragmentShaderObject != 0) { gl.glDeleteShader(fragmentShaderObject); } } and this is the error: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069aa42b9, pid=6856, tid=2776 # # JRE version: 6.0_17-b04 # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [atio6axx.dll+0xa742b9] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # GLProfile.getDefault().hasGLSL() return true. I stepped through it and noticed that the error occures at the very first instruction. I am running Windows 7 64 bit with a 64 bit Java VM (java 6). Ma Graphics card is a ATI Radeon HD 4600 Series. The ccc prints me an OpenGL version of 6.14.10.8787. |
Administrator
|
Hi
Something is wrong with your driver, I don't have such problems whereas I use shaders on an NVIDIA Quadro FX. Sven, do we have a unit test for shaders?
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Xfel
I've noticed similar HotSpot crashes on an ATI machine since b271. I just submitted a but report at https://jogamp.org/bugzilla/show_bug.cgi?id=480. You might try using b270 -- if that works, you've got the same problem.
|
Administrator
|
Nice catch. My previous ATI graphics card does not support shaders so I haven't reproduced this bug. Have you found which part of the source code causes such crashes? It seems to be a vendor specific problem.
Julien Gouesse | Personal blog | Website
|
The VM crashes when i call glCreateProgram();
I tried the same program in an Ubuntu Linux on the same machine, and it worked fine. But i am not shure whether both are using the same JOGL build. |
I had a very similar problem. The solution may very well be to upgrades the drivers, but I managed to craft an hypothesis as to why.
Thing is, the hasGL() method may return true, but some GL extensions may not be supported (such as GL_MULTISAMPLE) that your shader code will try to use. So when you create the program, during the linking process, it will try to find an internal method with this extension, and will probably create a segmentation fault, thereby crashing your JVM. That ONLY workaround I've found so far, one that does not rely on the driver not to implode when trying to compile a Shader, is to pre-check the extensions, then decide if you will even try to compile the shader. Granted, it's a royal pain in the ass to find which extensions will be used by a particular shader. So far, I've only been able to using trial and error. Extension lists documentation for OpenGL are very hard to find. |
In reply to this post by Xfel
I had a very similar problem. The solution may very well be to upgrades the drivers, but I managed to craft an hypothesis as to why.
Thing is, the hasGL() method may return true, but some GL extensions may not be supported (such as GL_MULTISAMPLE) that your shader code will try to use. So when you create the program, during the linking process, it will try to find an internal method with this extension, and will probably create a segmentation fault, thereby crashing your JVM. That ONLY workaround I've found so far, one that does not rely on the driver not to implode when trying to compile a Shader, is to pre-check the extensions, then decide if you will even try to compile the shader. Granted, it's a royal pain in the ass to find which extensions will be used by a particular shader. So far, I've only been able to using trial and error. Extension lists documentation for OpenGL are very hard to find. |
Administrator
|
In reply to this post by Wade Walker
On Sunday, March 06, 2011 11:22:25 Wade Walker [via jogamp] wrote:
> > I've noticed similar HotSpot crashes on an ATI machine since b271. I just > submitted a but report at https://jogamp.org/bugzilla/show_bug.cgi?id=480. > You might try using b270 -- if that works, you've got the same problem. > > j com.jogamp.opengl.impl.windows.wgl.WGLExtImpl.dispatch_wglGetPixelFormatAttribivARB1(JIIILjava/lang/Object;IZLjava/lang/Object;IZJ)Z+0 j com.jogamp.opengl.impl.windows.wgl.WGLExtImpl.wglGetPixelFormatAttribivARB(JIII[II[II)Z+166 j com.jogamp.opengl.impl.windows.wgl.WindowsWGLGraphicsConfiguration.wglAllARBPFIDs(Lcom/jogamp/opengl/impl/windows/wgl/WindowsWGLContext;J)[I+32 I have seen such native crashes before, I remember. The case was if eg some feature was not available, like pbuffer, but JOGL still queried for it. Hmm ... ~Sven |
Well, I tried it on ubuntu linux 10.10 on the same computer, and everything was fine. seems to be a windows specific bug.
|
Administrator
|
Try putting GLProfile.initSingleton( false or true ) in a static block in your program, then setting the debug flags "-Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all" to your JVM. If this makes it work on Windows, or changes the crash somehow, that means the ATI driver is crashing due to lack of a current GL context (same as bug 480). Just make sure the static block is executed on the same thread as your shader program creation, or this won't work.
|
In reply to this post by Xfel
Are you sure that your shader is running right?
Try to catch shader link and compile errors. IntBuffer params = Buffers.newDirectIntBuffer(1); gl.glGetObjectParameterivARB(vertexShaderObject, GL2.GL_COMPILE_STATUS, params); IntBuffer fragmentShaderObjectParams = Buffers.newDirectIntBuffer(1); gl.glGetObjectParameterivARB(fragmentShaderObject, GL2.GL_COMPILE_STATUS, fragmentShaderObjectParams); if (params.get(0) == 0 || fragmentShaderObjectParams.get(0) == 0) { ByteBuffer LogBuffer = ByteBuffer.allocate(10000); if (params.get(0) == 0 && fragmentShaderObjectParams.get(0) == 0) { gl.glGetShaderInfoLog(vertexShaderObject, 10000, shaderLength, LogBuffer); } else if (params.get(0) == 0) { gl.glGetShaderInfoLog(vertexShaderObject, 10000, shaderLength, LogBuffer); } else if (fragmentShaderObjectParams.get(0) == 0) { gl.glGetShaderInfoLog(vertexShaderObject, 10000, shaderLength, LogBuffer); } gl.glGetShaderInfoLog(vertexShaderObject, 10000, shaderLength, LogBuffer); String Log; try { Log = new String(LogBuffer.array(), "UTF-8"); } catch (UnsupportedEncodingException ex) { Log = new String(LogBuffer.array()); Logger.getLogger(Shader.class.getName()).log(Level.SEVERE, null, ex); } System.out.println(Log); } else { ProgramObject = gl.glCreateProgram(); gl.glAttachShader(ProgramObject, vertexShaderObject); gl.glAttachShader(ProgramObject, fragmentShaderObject); gl.glLinkProgram(ProgramObject); IntBuffer linked = Buffers.newDirectIntBuffer(1); gl.glGetProgramiv(ProgramObject, GL2.GL_LINK_STATUS, linked); if (linked.get(0) == 0) { ByteBuffer LogBuffer = ByteBuffer.allocate(10000); gl.glGetShaderInfoLog(ProgramObject, 10000, shaderLength, LogBuffer); String Log; try { Log = new String(LogBuffer.array(), "UTF-8"); } catch (UnsupportedEncodingException ex) { Log = new String(LogBuffer.array()); Logger.getLogger(Shader.class.getName()).log(Level.SEVERE, null, ex); } ProgramObject = 0; System.out.println(Log); } And Are you sure that it is shader? Try to debug code to the string where VM crushes. |
It is not the shader. The program already crashed at glCreateProgram(). if I would use your code, I wouldn't even reach it.
However, a driver update fixted the problem. but I still think that JOGL should catch this crash. |
Free forum by Nabble | Edit this page |