Bug 98699 - "float[a+++4 ? 1:1] f;" crashes glsl_compiler
Summary: "float[a+++4 ? 1:1] f;" crashes glsl_compiler
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Tapani Pälli
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-12 21:56 UTC by Karol Herbst
Modified: 2018-08-09 18:57 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
the bad shader (44 bytes, text/plain)
2016-11-12 21:56 UTC, Karol Herbst
Details
simplier version of the crashing shader (42 bytes, text/plain)
2016-11-13 09:48 UTC, Karol Herbst
Details

Description Karol Herbst 2016-11-12 21:56:22 UTC
Created attachment 127941 [details]
the bad shader

backtrace:

#0  0x00007ffff6d794eb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff6d7aa71 in __GI_abort () at abort.c:89
#2  0x00007ffff6d72309 in __assert_fail_base (fmt=0x7ffff6eb4e90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x754209 "dummy_instructions.is_empty()", 
    file=file@entry=0x74ea28 "../../../src/compiler/glsl/ast_to_hir.cpp", line=line@entry=2252, 
    function=function@entry=0x753de0 <process_array_size(exec_node*, _mesa_glsl_parse_state*)::__PRETTY_FUNCTION__> "unsigned int process_array_size(exec_node*, _mesa_glsl_parse_state*)") at assert.c:92
#3  0x00007ffff6d723b3 in __GI___assert_fail (assertion=assertion@entry=0x754209 "dummy_instructions.is_empty()", file=file@entry=0x74ea28 "../../../src/compiler/glsl/ast_to_hir.cpp", line=line@entry=2252, 
    function=function@entry=0x753de0 <process_array_size(exec_node*, _mesa_glsl_parse_state*)::__PRETTY_FUNCTION__> "unsigned int process_array_size(exec_node*, _mesa_glsl_parse_state*)") at assert.c:101
#4  0x0000000000604c8b in process_array_size (state=<optimized out>, node=0x9d5e78) at ../../../src/compiler/glsl/ast_to_hir.cpp:2252
#5  process_array_type (loc=loc@entry=0x7fffffffd170, base=<optimized out>, array_specifier=<optimized out>, state=state@entry=0x9d4880) at ../../../src/compiler/glsl/ast_to_hir.cpp:2278
#6  0x0000000000627805 in ast_type_specifier::glsl_type (state=0x9d4880, name=<synthetic pointer>, this=0x9d5a00) at ../../../src/compiler/glsl/ast_to_hir.cpp:2332
#7  ast_fully_specified_type::glsl_type (state=0x9d4880, name=<synthetic pointer>, this=<optimized out>) at ../../../src/compiler/glsl/ast_to_hir.cpp:2612
#8  ast_declarator_list::hir (this=0x9d87e8, instructions=0x9e7390, state=0x9d4880) at ../../../src/compiler/glsl/ast_to_hir.cpp:4552
#9  0x0000000000634a3f in ast_compound_statement::hir (state=0x9d4880, instructions=0x9e7390, this=0x9d8850) at ../../../src/compiler/glsl/ast_to_hir.cpp:2180
#10 ast_function_definition::hir (this=0x9d88b0, instructions=<optimized out>, state=0x9d4880) at ../../../src/compiler/glsl/ast_to_hir.cpp:5733
#11 0x000000000061e041 in _mesa_ast_to_hir (instructions=0x9d6550, state=state@entry=0x9d4880) at ../../../src/compiler/glsl/ast_to_hir.cpp:154
#12 0x000000000045bdc3 in _mesa_glsl_compile_shader (ctx=ctx@entry=0x995aa0 <standalone_compile_shader::local_ctx>, shader=shader@entry=0x9d2960, dump_ast=<optimized out>, dump_hir=<optimized out>)
    at ../../../src/compiler/glsl/glsl_parser_extras.cpp:1926
#13 0x000000000040b2e3 in compile_shader (shader=0x9d2960, ctx=0x995aa0 <standalone_compile_shader::local_ctx>) at ../../../src/compiler/glsl/standalone.cpp:353
#14 standalone_compile_shader (_options=_options@entry=0x995a50 <options>, num_files=num_files@entry=1, files=<optimized out>) at ../../../src/compiler/glsl/standalone.cpp:467
#15 0x0000000000405a26 in main (argc=<optimized out>, argv=0x7fffffffd628) at ../../../src/compiler/glsl/main.cpp:92
Comment 1 Karol Herbst 2016-11-13 09:48:14 UTC
Created attachment 127945 [details]
simplier version of the crashing shader
Comment 2 Ian Romanick 2016-11-15 19:31:39 UTC
I don't even want to know how you came across that. :)  Just looking at the backtrace, it seems the problem is the "a++" generates an assignment.  The code that handles array sizes doesn't anticipate any why for there to be anything other than an expression tree without side-effects, so it fails the assertion.  The grammar doesn't allow anything else inside [] that would generate an assignment, and I apparently didn't think about post-increment and friends.

Other things like function calls with out or inout parameters might also hit this.  It would be good to have a set of piglit tests to exercise this.  If you can write the tests, I should be able to fix Mesa. :)
Comment 3 Ian Romanick 2016-11-15 19:33:13 UTC
(In reply to Ian Romanick from comment #2)
> Other things like function calls with out or inout parameters might also hit
> this.  It would be good to have a set of piglit tests to exercise this.  If
> you can write the tests, I should be able to fix Mesa. :)

It seems Ken already has patches out on the mailing list.
Comment 4 Kenneth Graunke 2016-11-15 19:39:19 UTC
My patches for Karol's other crashes have landed, but I haven't looked at this one.
Comment 5 Ian Romanick 2016-11-15 19:45:40 UTC
(In reply to Kenneth Graunke from comment #4)
> My patches for Karol's other crashes have landed, but I haven't looked at
> this one.

This may be fixed by the fix for bug #98694.  The backtrace looks similar / the same.

Karol: Does that patch also fix this crash?
Comment 6 Karol Herbst 2016-11-15 20:51:00 UTC
no, it doesn't. Just tested on current master.
Comment 7 Tapani Pälli 2018-08-09 10:09:41 UTC
commit 03a5acec687454c7fe227b4bdd2db97d515f1af7
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Tue Aug 7 08:20:29 2018 +0300

    glsl: handle error case with ast_post_inc, ast_post_dec
    
    Return ir_rvalue::error_value with ast_post_inc, ast_post_dec if
    parser error was emitted previously. This way process_array_size
    won't see bogus IR generated like with commit 9c676a64273.
    
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98699
    Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Comment 8 Mark Janes 2018-08-09 18:48:46 UTC
Tapani: should we have a piglit test for this?
Comment 9 Tapani Pälli 2018-08-09 18:57:30 UTC
Sure, I'll write a test!


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.