Bug 18659 - Crash in shader/slang/slang_codegen.c _slang_gen_function_call_name()
Crash in shader/slang/slang_codegen.c _slang_gen_function_call_name()
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Mesa core
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks: 29044
  Show dependency treegraph
 
Reported: 2008-11-21 14:12 UTC by francois.bertel
Modified: 2010-08-17 09:06 UTC (History)
0 users

See Also:


Attachments
a glsl fragment shader used in VTK (1.17 KB, text/plain)
2008-11-21 14:12 UTC, francois.bertel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description francois.bertel 2008-11-21 14:12:56 UTC
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
Comment 1 Brian Paul 2008-11-21 16:27:25 UTC
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.
Comment 2 francois.bertel 2008-11-23 15:28:46 UTC
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?)
Comment 3 Brian Paul 2008-11-24 16:26:26 UTC
We probably won't support true linking for a while.  There's other things higher on the list.
Comment 4 ajax at nwnk dot net 2009-08-24 12:31:08 UTC
Mass version move, cvs -> git
Comment 5 Eric Anholt 2010-08-17 09:06:07 UTC
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.