Commen=
t # 9
on bug 10692=
8
from Roland Scheidegger
(In reply to ubizjak from comment #7)
> Please configure the build with:
>=20
> CXXFLAGS=3D"-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 =3D std::vector of length 2, capacity 3 =3D {0x7f94d905d110, 0x7f94d905=
cf70}}
And trying to access element src[2].
There's an early exit in the function if src.size() is < 3. Since this d=
idn'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 retu=
rn
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_nod=
e& n) {
if (!sh.safe_math && (n.bc.op_ptr->flags & AF_M_ASSO=
C)) {
if (fold_assoc(&n))
return true;
+ else if (n.src.size() < 3)
+ return fold_alu_op2(n);
}
value* v0 =3D 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 =3D=20
Thread 1 "glretrace" received signal SIGSEGV, Segmentation fault.
...
#3 0x00007ffff36538cb in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<r600_sb::reg=
ion_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=3D (this=3D=
0x7fffffffb840,
__x=3D) 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=3D (th=
is=3D0x7fffffffb840) at
/usr/include/c++/4.8/bits/stl_iterator.h:96
#5 r600_sb::if_conversion::run (this=3D0x7fffffffbee0) at
sb/sb_if_conversion.cpp:46
#6 0x00007ffff3632765 in r600_sb_bytecode_process (rctx=3D0x10e4660,
bc=3D0x1980bf0, pshader=3D0x1980be8, dump_bytecode=3D1, optimize=3D1) at
sb/sb_core.cpp:195
I don't know though if that's just due to the D_GLIBCXX_DEBUG thing or it w=
ill
also cause crashes without it in some other libstdc++ versions... (in any c=
ase,
it probably should be fixed, but this code isn't my area of expertise).