Comment # 9
on bug 106928
from Roland Scheidegger
(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 = "" 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
