<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)" href="https://bugs.freedesktop.org/show_bug.cgi?id=94955#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)" href="https://bugs.freedesktop.org/show_bug.cgi?id=94955">bug 94955</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Brian Paul from <a href="show_bug.cgi?id=94955#c1">comment #1</a>) > (In reply to David Lonie from <a href="show_bug.cgi?id=94955#c0">comment #0</a>) > > ==32054== Conditional jump or move depends on uninitialised value(s) > > ==32054== at 0x5409DEE: lp_build_blend_factor_unswizzled > > (lp_bld_blend_aos.c:98) > > ==32054== by 0x540A2A5: lp_build_blend_factor (lp_bld_blend_aos.c:262) > > ==32054== by 0x540A53C: lp_build_blend_aos (lp_bld_blend_aos.c:352) > > ==32054== by 0x543C200: generate_unswizzled_blend (lp_state_fs.c:2094) > > ==32054== by 0x543D32D: generate_fragment (lp_state_fs.c:2434) > > ==32054== by 0x543DEAC: generate_variant (lp_state_fs.c:2619) > > ==32054== by 0x543F464: llvmpipe_update_fs (lp_state_fs.c:3171) > > ==32054== by 0x5435D35: llvmpipe_update_derived (lp_state_derived.c:209) > > ==32054== by 0x5410AC0: llvmpipe_draw_vbo (lp_draw_arrays.c:70) > > ==32054== by 0x52E28C4: cso_draw_vbo (cso_context.c:1629) > > ==32054== by 0x5174712: st_draw_vbo (st_draw.c:251) > > ==32054== by 0x511BE24: vbo_validated_drawrangeelements > > (vbo_exec_array.c:844) > > I don't see what's wrong here. At lp_bld_blend_aos.c:98 we're examining > fields of the bld object. But the whole bld object is initialized to zeros > at line 321. The problem is we're later assigning it the src1_alpha value coming from the fs. And this one is only initialized if we have dual source blend. I'll see if I can fix this easily, as the warning is annoying (I've seen it before), however it is definitely 100% harmless and will not cause any issues whatsoever (the conditional assignment may rely on uninitialized values, however the assigned value will be unused anyway). > > > > > ==32054== Conditional jump or move depends on uninitialised value(s) > > ==32054== at 0x404002D: ??? > > ==32054== by 0x5415736: lp_rast_shade_quads_mask (lp_rast.c:457) > > ==32054== by 0x541999F: lp_rast_triangle_32_3_16 (lp_rast_tri.c:346) > > ==32054== by 0x5415A81: do_rasterize_bin (lp_rast.c:609) > > ==32054== by 0x5415AEF: rasterize_bin (lp_rast.c:628) > > ==32054== by 0x5415BFE: rasterize_scene (lp_rast.c:688) > > ==32054== by 0x5415EE3: thread_function (lp_rast.c:828) > > ==32054== by 0x5413C4A: impl_thrd_routine (threads_posix.h:87) > > ==32054== by 0x5BF6423: start_thread (in /usr/lib/libpthread-2.23.so) > > ==32054== by 0x720CCBC: clone (in /usr/lib/libc-2.23.so) > > Not sure about this one. I suspect our jitted code does some vector ops on > some unused elements and that triggers the valgrind warning, but that should > be harmless. Roland?? This one is actually really annoying, as it turns up everywhere and thus makes valgrind output spammy. I'm quite convinced it's completely harmless, but so far I've been unable to eliminate it... But in any case, I HIGHLY doubt these two are the reason for any random segfaults, I certainly don't see any evidence here. So, a backtrace of the actual crash would probably be more useful.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>