[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Brian Paul from comment #1)
> (In reply to David Lonie from comment #0)
> > ==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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160415/184bc044/attachment.html>