Bug 98694 - "(5=2)?1:1" as array size decleration crashes glsl_compiler
Summary: "(5=2)?1:1" as array size decleration 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: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-12 12:23 UTC by Karol Herbst
Modified: 2016-11-13 06:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
crashing vertex shader (39 bytes, text/plain)
2016-11-12 12:23 UTC, Karol Herbst
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karol Herbst 2016-11-12 12:23:41 UTC
Created attachment 127930 [details]
crashing vertex shader

The attached shader causes glsl_compiler to crash. Couldn't managed to make the example easier. The "(5=2)" is the important part to trigger that crash.
Comment 1 Karol Herbst 2016-11-12 12:24:18 UTC
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=0x754149 "dummy_instructions.is_empty()", 
    file=file@entry=0x74e968 "../../../src/compiler/glsl/ast_to_hir.cpp", line=line@entry=2249, 
    function=function@entry=0x753d20 <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=0x754149 "dummy_instructions.is_empty()", file=file@entry=0x74e968 "../../../src/compiler/glsl/ast_to_hir.cpp", line=line@entry=2249, 
    function=function@entry=0x753d20 <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=0x9d5d38) at ../../../src/compiler/glsl/ast_to_hir.cpp:2249
#5  process_array_type (loc=loc@entry=0x7fffffffd190, base=<optimized out>, array_specifier=<optimized out>, state=state@entry=0x9d4870) at ../../../src/compiler/glsl/ast_to_hir.cpp:2275
#6  0x00000000006277f5 in ast_type_specifier::glsl_type (state=0x9d4870, name=<synthetic pointer>, this=0x9d59f0) at ../../../src/compiler/glsl/ast_to_hir.cpp:2329
#7  ast_fully_specified_type::glsl_type (state=0x9d4870, name=<synthetic pointer>, this=<optimized out>) at ../../../src/compiler/glsl/ast_to_hir.cpp:2609
#8  ast_declarator_list::hir (this=0x9d5f78, instructions=0x9e7350, state=0x9d4870) at ../../../src/compiler/glsl/ast_to_hir.cpp:4549
#9  0x0000000000634a2f in ast_compound_statement::hir (state=0x9d4870, instructions=0x9e7350, this=0x9d8580) at ../../../src/compiler/glsl/ast_to_hir.cpp:2177
#10 ast_function_definition::hir (this=0x9d85e0, instructions=<optimized out>, state=0x9d4870) at ../../../src/compiler/glsl/ast_to_hir.cpp:5730
#11 0x000000000061e031 in _mesa_ast_to_hir (instructions=0x9d6540, state=state@entry=0x9d4870) 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=0x7fffffffd648) at ../../../src/compiler/glsl/main.cpp:92
Comment 2 Kenneth Graunke 2016-11-12 20:48:29 UTC
Fix on list:
https://lists.freedesktop.org/archives/mesa-dev/2016-November/135132.html
Comment 3 Kenneth Graunke 2016-11-13 06:12:11 UTC
Fixed by:

commit 9c676a64273f32c7fb3f2b6973399af1d7f24d46
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Sat Nov 12 11:27:17 2016 -0800

    glsl: Fix assert fails when assignment expressions are in array sizes.
    
    Karol Herbst's fuzzing efforts discovered that we would hit the
    following assert:
    
       assert(dummy_instructions.is_empty());
    
    when processing an illegal array size expression of
    
       float[(1=1)?1:1] t;
    
    In do_assignment, we realized we needed an rvalue for (1 = 1), and
    generated a temporary variable and assignment from the RHS.  We've
    already flagged an error (non-lvalue in assignment), and return a bogus
    value as the rvalue.  But process_array_size sees the bogus value, which
    happened to be a constant expression, and rightly assumes that
    processing a constant expression shouldn't have generated any code.
    instructions.
    
    To handle this, make do_assignment not generate any temps or assignments
    when it's already raised an error - just return an error value directly.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98694
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    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.