Bug 110441 - [llvmpipe] complex-loop-analysis-bug regression
Summary: [llvmpipe] complex-loop-analysis-bug regression
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: 19.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, have-backtrace, regression
Depends on:
Blocks:
 
Reported: 2019-04-15 18:16 UTC by Vinson Lee
Modified: 2019-04-15 22:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Vinson Lee 2019-04-15 18:16:28 UTC
$ ./bin/shader_runner tests/shaders/complex-loop-analysis-bug.shader_test -auto
shader_runner: src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1111: get_indirect_index: Assertion `index_limit > 0' failed.
Aborted (core dumped)


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f0b7ae03535 in __GI_abort () at abort.c:79
#2  0x00007f0b7ae0340f in __assert_fail_base (fmt=0x7f0b7af8f858 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f0b7a62be0e "index_limit > 0", file=0x7f0b7a62b988 "src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c", line=1111, function=<optimized out>) at assert.c:92
#3  0x00007f0b7ae13142 in __GI___assert_fail (assertion=0x7f0b7a62be0e "index_limit > 0", file=0x7f0b7a62b988 "src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c", line=1111, function=0x7f0b7a62c630 <__PRETTY_FUNCTION__.15983> "get_indirect_index") at assert.c:101
#4  0x00007f0b7a444064 in get_indirect_index (bld=0x7ffdf2830120, reg_file=2, reg_index=0, indirect_reg=0x55d4010317b4, index_limit=0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1111
#5  0x00007f0b7a445212 in emit_fetch_input (bld_base=0x7ffdf2830120, reg=0x55d4010317b0, stype=TGSI_TYPE_FLOAT, swizzle_in=0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1442
#6  0x00007f0b7a4b5d1c in lp_build_emit_fetch_src (bld_base=0x7ffdf2830120, reg=0x55d4010317b0, stype=TGSI_TYPE_FLOAT, chan_index=0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:370
#7  0x00007f0b7a4b5f59 in lp_build_emit_fetch (bld_base=0x7ffdf2830120, inst=0x55d401031780, src_op=0, chan_index=0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:450
#8  0x00007f0b7a4b5421 in lp_build_fetch_args (bld_base=0x7ffdf2830120, emit_data=0x7ffdf282fea0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:180
#9  0x00007f0b7a4b58b4 in lp_build_tgsi_inst_llvm (bld_base=0x7ffdf2830120, inst=0x55d401031780) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:293
#10 0x00007f0b7a4b63be in lp_build_tgsi_llvm (bld_base=0x7ffdf2830120, tokens=0x55d401026e40) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:555
#11 0x00007f0b7a44b1b4 in lp_build_tgsi_soa (gallivm=0x55d400fe2860, tokens=0x55d401026e40, type=..., mask=0x7ffdf28363a0, consts_ptr=0x55d4010217e8, const_sizes_ptr=0x55d400fdc618, system_values=0x7ffdf28363c0, inputs=0x7ffdf2839680, outputs=0x7ffdf28364a0, 
    context_ptr=0x55d401023ce0, thread_data_ptr=0x55d401023e70, sampler=0x55d40101dcb0, info=0x55d400fd9d28, gs_iface=0x0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:4001
#12 0x00007f0b79caa1cc in generate_fs_loop (gallivm=0x55d400fe2860, shader=0x55d400fd9c00, key=0x55d400fe15d0, builder=0x55d401024ee0, type=..., context_ptr=0x55d401023ce0, num_loop=0x55d401025800, interp=0x7ffdf2837750, sampler=0x55d40101dcb0, mask_store=0x55d400fe4508, 
    out_color=0x7ffdf2837110, depth_ptr=0x55d401023e20, depth_stride=0x55d401023ec0, facing=0x55d401023d58, thread_data_ptr=0x55d401023e70) at src/gallium/drivers/llvmpipe/lp_state_fs.c:478
#13 0x00007f0b79cb14d0 in generate_fragment (lp=0x55d400df87a0, shader=0x55d400fd9c00, variant=0x55d400fe15d0, partial_mask=1) at src/gallium/drivers/llvmpipe/lp_state_fs.c:2624
#14 0x00007f0b79cb2486 in generate_variant (lp=0x55d400df87a0, shader=0x55d400fd9c00, key=0x7ffdf283a200) at src/gallium/drivers/llvmpipe/lp_state_fs.c:2872
#15 0x00007f0b79cb3c60 in llvmpipe_update_fs (lp=0x55d400df87a0) at src/gallium/drivers/llvmpipe/lp_state_fs.c:3451
#16 0x00007f0b79ca8666 in llvmpipe_update_derived (llvmpipe=0x55d400df87a0) at src/gallium/drivers/llvmpipe/lp_state_derived.c:210
#17 0x00007f0b79c82e36 in llvmpipe_draw_vbo (pipe=0x55d400df87a0, info=0x7ffdf283a9a0) at src/gallium/drivers/llvmpipe/lp_draw_arrays.c:70
#18 0x00007f0b7a33cd4c in cso_draw_vbo (cso=0x55d400fe74d0, info=0x7ffdf283a9a0) at src/gallium/auxiliary/cso_cache/cso_context.c:1708
#19 0x00007f0b79f1f2a1 in st_draw_vbo (ctx=0x55d400e4bfd0, prims=0x7ffdf283aa60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0, stream=0, indirect=0x0) at src/mesa/state_tracker/st_draw.c:271
#20 0x00007f0b79f8ac8f in _mesa_draw_arrays (ctx=0x55d400e4bfd0, mode=5, start=0, count=4, numInstances=1, baseInstance=0, drawID=0) at src/mesa/main/draw.c:374
#21 0x00007f0b79f8b750 in _mesa_DrawArrays (mode=5, start=0, count=4) at src/mesa/main/draw.c:531
#22 0x00007f0b7b0b8404 in stub_glDrawArrays (mode=5, first=0, count=4) at tests/util/piglit-dispatch-gen.c:12181
#23 0x00007f0b7b1278cd in piglit_draw_rect_from_arrays (verts=0x7ffdf283ab80, tex=0x0, use_patches=false, instance_count=1) at tests/util/piglit-util-gl.c:701
#24 0x00007f0b7b127d4d in piglit_draw_rect_custom (x=-1, y=-1, w=2, h=2, use_patches=false, instance_count=1) at tests/util/piglit-util-gl.c:823
#25 0x00007f0b7b127da3 in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at tests/util/piglit-util-gl.c:832
#26 0x000055d3ff7389eb in piglit_display () at tests/shaders/shader_runner.c:3614
#27 0x00007f0b7b152350 in process_next_event (x11_fw=0x55d400dd27b0) at tests/util/piglit-framework-gl/piglit_x11_framework.c:137
#28 0x00007f0b7b152410 in enter_event_loop (winsys_fw=0x55d400dd27b0) at tests/util/piglit-framework-gl/piglit_x11_framework.c:153
#29 0x00007f0b7b150b83 in run_test (gl_fw=0x55d400dd27b0, argc=2, argv=0x7ffdf283b2c8) at tests/util/piglit-framework-gl/piglit_winsys_framework.c:88
#30 0x00007f0b7b132568 in piglit_gl_test_run (argc=2, argv=0x7ffdf283b2c8, config=0x7ffdf283b180) at tests/util/piglit-framework-gl.c:229
#31 0x000055d3ff72f85e in main (argc=2, argv=0x7ffdf283b2c8) at tests/shaders/shader_runner.c:72
(gdb) frame 4
#4  0x00007f0b7a444064 in get_indirect_index (bld=0x7ffdf2830120, reg_file=2, reg_index=0, indirect_reg=0x55d4010317b4, index_limit=0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1111
1111	      assert(index_limit > 0);
(gdb) print index_limit
$1 = 0


a3c898dc97ec5f0e0b93b2ee180bdf8ca3bab14c is the first bad commit
commit a3c898dc97ec5f0e0b93b2ee180bdf8ca3bab14c
Author: Roland Scheidegger <sroland@vmware.com>
Date:   Thu Nov 8 02:52:47 2018 +0100

    gallivm: fix improper clamping of vertex index when fetching gs inputs
    
    Because we only have one file_max for the (2d) gs input file, the value
    actually represents the max of attrib and vertex index (although I'm
    not entirely sure if we really want the max, since the max valid value
    of the vertex dimension can be easily deduced from the input primitive).
    
    Thus in cases where the number of inputs is higher than the number of
    vertices per prim, we did not properly clamp the vertex index, which
    would result in out-of-bound fetches, potentially causing segfaults
    (the segfaults seemed actually difficult to trigger, but valgrind
    certainly wasn't happy). This might have happened even if the shader
    did not actually try to fetch bogus vertices, if the fetching happened
    in non-active conditional clauses.
    
    To fix simply use the correct max vertex index value (derived from
    the input prim type) instead when clamping for this case.
    
    Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

:040000 040000 c8333342db18da642f4ddcebe7c07c88374adfcc 85704b2467ded236dcf436a4151c6823a92fb28b M	src
bisect run success
Comment 1 Roland Scheidegger 2019-04-15 19:28:41 UTC
At a glance, it seems the code is correct, just the assertion is wrong. 0 is a valid value as file_max (as it's the highest allowed value).
I guess this is rarely seen in practice because this happens with array declarations which have size 1, which is somewhat unusual (and will lead to inefficient code here I suppose), nevertheless the code can handle this just fine. I'll whip up a fix...
Comment 2 Dylan Baker 2019-04-15 21:15:55 UTC
Vinson, please don't add bugs to release trackers after that release has already happened.
Comment 3 Roland Scheidegger 2019-04-15 22:52:45 UTC
Fixed by 88e0bbf24aa82000195d10c7873f881d190b825b.


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.