| Summary: | Segfault when compiling shader with a subroutine that takes a parameter | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Nicolas Koch <nioko1337> |
| Component: | glsl-compiler | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | airlied, nioko1337 |
| Version: | 11.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
There is something fishy going on. I tried to compile this as a stand-alone shader (using glslparsertest from piglit), and I was able to reproduce the segfault.
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff123d4b2 in ir_call::ir_call (this=0xbbb7f0, callee=0x0, return_deref=0xbbb610, actual_parameters=0xbba6a0) at ir.h:1755
1755 assert(callee->return_type != NULL);
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.6-19.fc23.x86_64 elfutils-libelf-0.163-4.fc23.x86_64 elfutils-libs-0.163-4.fc23.x86_64 expat-2.1.0-12.fc23.x86_64 libattr-2.4.47-14.fc23.x86_64 libcap-2.24-8.fc23.x86_64 libgcc-5.3.1-2.fc23.x86_64 libpng-1.6.19-1.fc23.x86_64 libselinux-2.4-4.fc23.x86_64 libstdc++-5.3.1-2.fc23.x86_64 pcre-8.38-4.fc23.x86_64 systemd-libs-222-10.fc23.x86_64 waffle-1.5.0-4.fc23.x86_64 xz-libs-5.2.1-3.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
(gdb) bt
#0 0x00007ffff123d4b2 in ir_call::ir_call (this=0xbbb7f0, callee=0x0, return_deref=0xbbb610, actual_parameters=0xbba6a0) at ir.h:1755
#1 0x00007ffff12e60dc in (anonymous namespace)::lower_subroutine_visitor::visit_leave (this=0x7fffffffd920, ir=0xbba670) at lower_subroutine.cpp:95
#2 0x00007ffff12a5065 in ir_call::accept (this=0xbba670, v=0x7fffffffd920) at ir_hv_accept.cpp:341
#3 0x00007ffff12a43ce in visit_list_elements (v=0x7fffffffd920, l=0x792618, statement_list=true) at ir_hv_accept.cpp:55
#4 0x00007ffff12a45d3 in ir_function_signature::accept (this=0x7925d0, v=0x7fffffffd920) at ir_hv_accept.cpp:115
#5 0x00007ffff12a43ce in visit_list_elements (v=0x7fffffffd920, l=0x792458, statement_list=false) at ir_hv_accept.cpp:55
#6 0x00007ffff12a4667 in ir_function::accept (this=0x792430, v=0x7fffffffd920) at ir_hv_accept.cpp:127
#7 0x00007ffff12a43ce in visit_list_elements (v=0x7fffffffd920, l=0x778370, statement_list=true) at ir_hv_accept.cpp:55
#8 0x00007ffff12e5ecc in lower_subroutine (instructions=0x778370, state=0x776e70) at lower_subroutine.cpp:57
#9 0x00007ffff127e5a6 in _mesa_glsl_compile_shader (ctx=0x7ffff7f78040, shader=0x776920, dump_ast=false, dump_hir=false) at glsl_parser_extras.cpp:1762
#10 0x00007ffff10562fe in compile_shader (ctx=0x7ffff7f78040, shaderObj=1) at main/shaderapi.c:986
#11 0x00007ffff1056c26 in _mesa_CompileShader (shaderObj=1) at main/shaderapi.c:1273
#12 0x00007ffff7aa7c76 in stub_glCompileShader (shader=1) at tests/util/piglit-dispatch-gen.c:6896
#13 0x0000000000401f12 in test () at tests/glslparsertest/glslparsertest.c:308
#14 0x00000000004026b0 in piglit_init (argc=4, argv=0x7fffffffdce8) at tests/glslparsertest/glslparsertest.c:548
#15 0x00007ffff7b3e67c in run_test (gl_fw=0x616c40, argc=4, argv=0x7fffffffdce8) at tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
#16 0x00007ffff7b2321f in piglit_gl_test_run (argc=4, argv=0x7fffffffdce8, config=0x7fffffffdba0) at tests/util/piglit-framework-gl.c:199
#17 0x000000000040195e in main (argc=4, argv=0x7fffffffdce8) at tests/glslparsertest/glslparsertest.c:90
(gdb) print callee
$1 = (ir_function_signature *) 0x0
It appears that fn->exact_matching_signature is failing to find a matching signature. This is especially odd since type sub_var type and the parameter list don't match at all.
(gdb) print ir->sub_var->type->name
$6 = 0x778760 "modify_t"
(gdb) call exec_list_is_empty(&ir->actual_parameters)
$7 = true
(gdb) print *ir->callee->_function
$8 = {<ir_instruction> = {<exec_node> = {next = 0x7831b8, prev = 0x7825b8}, _vptr.ir_instruction = 0x7ffff183e840 <vtable for ir_function+16>, ir_type = ir_type_function}, name = 0x782a10 "modify_t", signatures = {head = 0x782a68, tail = 0x0, tail_pred = 0x782a68},
is_subroutine = true, num_subroutine_types = 0, subroutine_types = 0x0, subroutine_index = -1}
I think having subroutines with parameters is just broken. I simplified the test to have just one subroutine type, and it still hits the same segfault. I have sent a test case to the piglit mailing list:
http://patchwork.freedesktop.org/patch/70571/
Nice work, and really fast respond times! I have found a few more bugs wrt subroutines, but those are not compiler bugs. To be more specific, the implementation of `UniformSubroutinesuiv` seems to be buggy when the user specified a custom uniform location with `layout( location = x)`. Since I'm not really familiar with mesa internals, in which bugtracker category would I submit such a bug? Thanks in advance. (In reply to Nicolas Koch from comment #2) > Nice work, and really fast respond times! > > I have found a few more bugs wrt subroutines, but those are not compiler > bugs. > > To be more specific, the implementation of `UniformSubroutinesuiv` seems to > be buggy when the user specified a custom uniform location with `layout( > location = x)`. > > Since I'm not really familiar with mesa internals, in which bugtracker > category would I submit such a bug? > Thanks in advance. This can be either compiler or Mesa core bug, file a bug against glsl-compiler or Mesa core, thanks! Thanks, I submitted the bug here: https://bugs.freedesktop.org/show_bug.cgi?id=93731 Sorry I didn't have a minimal running example, but I'm really horrible at the raw OpenGL side of things. does http://cgit.freedesktop.org/~airlied/mesa/commit/?h=arb_gpu_shader_fp64-fixes&id=a183d4f5d0dd191f4c11a6f30c8850f2dbf11df3 fix this? I wrote this ages ago when running CTS and haven't sent it out yet. Yes it does! Please merge asap =D Dave's patch landed in master. It should be in the next 11.0 and 11.1 releases. commit 119bef954379ebb35faf182b0b665becacddab76 Author: Dave Airlie <airlied@redhat.com> Date: Sun Jan 17 14:23:35 2016 +1000 glsl: fix subroutine lowering reusing actual parmaters One of the oglconform tests was crashing here, and it was due to not cloning the actual parameters before creating the new call. This makes a call clone function that does the right things to make sure we clone all the needed info, and points the callee at it. (It differs from ->clone due to this). this may fix https://bugs.freedesktop.org/show_bug.cgi?id=93722, I had this patch in my cts fixes tree, but hadn't had time to make sure I liked it. Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com> |
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.
The fragment shader in question: #version 330 #extension GL_ARB_shader_subroutine : require #extension GL_ARB_explicit_uniform_location : require out vec4 fragColor; subroutine vec4 color_t(); subroutine vec4 modify_t(vec4 color); subroutine uniform color_t Color; subroutine uniform modify_t Modify; subroutine(color_t) vec4 ColorRed() { return vec4(1, 0, 0, 1); } subroutine(color_t) vec4 ColorBlue() { return vec4(0, 0.4, 1, 1); } subroutine(modify_t) vec4 SwapRB(vec4 color) { return vec4(color.b, color.g, color.r, color.a); } subroutine(modify_t) vec4 DeleteR(vec4 color) { return vec4(0, color.g, color.b, color.a); } void main() { vec4 color = Color(); fragColor = Modify(color); } Some debug logs I could gather: [...] [OpenGL] CreateShader(35632) [OpenGL] ShaderSource(2, 1, 0x7fff29927210, 0x0) [OpenGL] CompileShader(2) An unknown error occurred dmesg output: [78197.436774] subroutines[12214]: segfault at 60 ip 00007f9d05705f70 sp 00007fff1f1da118 error 4 in i965_dri.so[7f9d0545c000+5d7000] Also happens when using llvm renderer: [78750.763639] subroutines[12766]: segfault at 60 ip 00007f25b4e88230 sp 00007fff299269f8 error 4 in swrast_dri.so[7f25b4bca000+86b000] This is my first bug report, so I'm not entirely sure if I'm doing this completely right.