Created attachment 20500 [details] a glsl fragment shader used in VTK Mesa git crashes with the following VTK test: TestTranslucentLUTDepthPeelingPass http://www.cdash.org/CDash/testDetails.php?test=12796458&build=216805 It passes with an nVidia Quadro FX 3600M with the driver from nVidia. In attachment is the glsl code. To reproduce the crash, I just copied the file into mesa/progs/glsl/ and change line 19 of brick.c to be: static char *FragProgFile = "vtkDepthPeeling_fs.glsl"; The crash happens when Mesa try to compile the shader. "brick" crashes like this: (gdb) r Starting program: /home/fbertel/install/mesa/mesa-git/mesa/progs/glsl/brick [Thread debugging using libthread_db enabled] Mesa: Initializing x86-64 optimizations Mesa: Mesa 7.3-devel DEBUG build Nov 18 2008 15:30:43 [New Thread 0x2b40a3c98680 (LWP 9342)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b40a3c98680 (LWP 9342)] 0x00002b40a1296b63 in _slang_gen_function_call_name (A=0x7fff0a148300, name=0x220e038 "propFuncFS", oper=0x2213420, dest=0x0) at shader/slang/slang_codegen.c:685 In this case "fun" is OK: (gdb) p fun $1 = (slang_function *) 0x22134f0 but "fun->body" is NULL: (gdb) p fun->body $2 = (slang_operation *) 0x0 So, of course, this is crashing: "fun->body->type" The complete stack is: (gdb) bt #0 0x00002b40a1296b63 in _slang_gen_function_call_name (A=0x7fff0a148300, name=0x220e038 "propFuncFS", oper=0x2213420, dest=0x0) at shader/slang/slang_codegen.c:685 #1 0x00002b40a1295821 in _slang_gen_operation (A=0x7fff0a148300, oper=0x2213420) at shader/slang/slang_codegen.c:3528 #2 0x00002b40a129594f in _slang_gen_operation (A=0x7fff0a148300, oper=0x220e110) at shader/slang/slang_codegen.c:3378 #3 0x00002b40a1298137 in _slang_codegen_function (A=0x7fff0a148300, fun=0x2213588) at shader/slang/slang_codegen.c:3963 #4 0x00002b40a11f58c6 in parse_code_unit (C=0x7fff0a1483a0, unit=0x2237f78, shader=0x6ebea0) at shader/slang/slang_compile.c:2235 #5 0x00002b40a11f5b3e in compile_binary (prod=<value optimized out>, unit=0x7fff0a147fd8, version=<value optimized out>, type=SLANG_UNIT_FRAGMENT_SHADER, infolog=0xfefefefefefefeff, builtin=0xff5e5245626d7445, downlink=0x8101010101010100, shader=0x6ebea0) at shader/slang/slang_compile.c:2276 #6 0x00002b40a11f603d in _slang_compile (ctx=0x6153f0, shader=0x6ebea0) at shader/slang/slang_compile.c:2343 #7 0x00002b40a11a5f3b in _mesa_compile_shader (ctx=0x6153f0, shaderObj=<value optimized out>) at shader/shader_api.c:1360 #8 0x000000000040208f in CompileShaderText (shaderType=35632, text=0x8f9b50 "// ", '=' <repeats 76 times>, "\n//\n// Program: Visualization Toolkit\n// Module: $RCSfile: vtkDepthPeeling_fs.glsl,v $\n//\n// Copyright (c) Ken Ma"...) at shaderutil.c:54 #9 0x000000000040263f in CompileShaderFile (shaderType=35632, filename=<value optimized out>) at shaderutil.c:91 #10 0x0000000000401a33 in main (argc=1, argv=0x7fff0a14b3a8) at brick.c:150
I've committed a fix to prevent the crash. However, an error is generated in this example. Mesa's GLSL compiler does not yet support true linking of shaders defined in multiple shader programs. That is, all your fragment shader code must be compiled at once with one call to glCompileShader(). Hopefully you can work around this limitation for the time being.
Your change ( 4f05893415a2d6f29b29f4daf991ea95a1891a81 ) fixed the VTK test, thanks: http://www.cdash.org/CDash/testDetails.php?test=12861380&build=217358 My algorithm is robust enough when probing the OpenGL capabilities: It first tests for the supported OpenGL versions/extensions. The second part is a try-compile operation like cmake or autoconf would do for a C/C++-compiler expect here it tests for the GLSL compiler. In the case of Mesa, my algorithm raises a flag to say the OpenGL implementation in use cannot support it and returns. When will the Mesa's GLSL compiler support true linking of shaders defined in multiple shader programs? (any plan or roadmap?)
We probably won't support true linking for a while. There's other things higher on the list.
Mass version move, cvs -> git
This testcase compiles under glsl2, and I don't know of any specific issues brought up with linking in this bug, so I think it's fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.