[Bug 106928] When starting a match Rocket League crashes on "Go"

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106928

--- Comment #9 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to ubizjak from comment #7)
> Please configure the build with:
> 
> CXXFLAGS="-Wp,-D_GLIBCXX_ASSERTIONS" ./autogen.sh

That didn't do anything neither. However I figured out the problem more or less
in the code, and some googling said that using -D_GLIBCXX_DEBUG should make it
trigger reliably, and indeed it does...
The issue is that (you already showed that actually)
src = std::vector of length 2, capacity 3 = {0x7f94d905d110, 0x7f94d905cf70}}
And trying to access element src[2].
There's an early exit in the function if src.size() is < 3. Since this didn't
hit, apparently fold_assoc() resized the vector. And indeed it can do that
(there's an explicit n->src.resize(2) somewhere, and it would still return
false in this case).

I think something like this should do:
diff --git a/src/gallium/drivers/r600/sb/sb_expr.cpp
b/src/gallium/drivers/r600/sb/sb_expr.cpp
index 1df78da660..c77b9f2d7d 100644
--- a/src/gallium/drivers/r600/sb/sb_expr.cpp
+++ b/src/gallium/drivers/r600/sb/sb_expr.cpp
@@ -945,6 +945,8 @@ bool expr_handler::fold_alu_op3(alu_node& n) {
        if (!sh.safe_math && (n.bc.op_ptr->flags & AF_M_ASSOC)) {
                if (fold_assoc(&n))
                        return true;
+               else if (n.src.size() < 3)
+                       return fold_alu_op2(n);
        }

        value* v0 = n.src[0]->gvalue();

But I'm not entirely convinced it's really the right thing to do (maybe what
fold_assoc() did isn't quite what it's supposed to do?).
It fixes the particular fold_alu_op3 crash for me, but the shader (not sure
it's actually the same one) crashes later anyway:
/usr/include/c++/4.8/debug/safe_iterator.h:225:
Error: attempt to copy from a singular iterator.

Objects involved in the operation:
    iterator "this" @ 0x0x7ffff3c71e80 {
      type = 
Thread 1 "glretrace" received signal SIGSEGV, Segmentation fault.
...
#3  0x00007ffff36538cb in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<r600_sb::region_node**,
std::__cxx1998::vector<r600_sb::region_node*,
std::allocator<r600_sb::region_node*> > >,
std::__debug::vector<r600_sb::region_node*,
std::allocator<r600_sb::region_node*> > >::operator= (this=0x7fffffffb840,
__x=) at /usr/include/c++/4.8/debug/safe_iterator.h:221
#4  0x00007ffff365376d in
std::reverse_iterator<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<r600_sb::region_node**,
std::__cxx1998::vector<r600_sb::region_node*,
std::allocator<r600_sb::region_node*> > >,
std::__debug::vector<r600_sb::region_node*,
std::allocator<r600_sb::region_node*> > > >::operator= (this=0x7fffffffb840) at
/usr/include/c++/4.8/bits/stl_iterator.h:96
#5  r600_sb::if_conversion::run (this=0x7fffffffbee0) at
sb/sb_if_conversion.cpp:46
#6  0x00007ffff3632765 in r600_sb_bytecode_process (rctx=0x10e4660,
bc=0x1980bf0, pshader=0x1980be8, dump_bytecode=1, optimize=1) at
sb/sb_core.cpp:195

I don't know though if that's just due to the D_GLIBCXX_DEBUG thing or it will
also cause crashes without it in some other libstdc++ versions... (in any case,
it probably should be fixed, but this code isn't my area of expertise).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180629/b0ee0f32/attachment.html>