<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#c4">Comment # 4</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 Roland Scheidegger from <a href="show_bug.cgi?id=94955#c2">comment #2</a>) > > > ==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... To elaborate on that, the problem is that some of those complaints from valgrind may be valid, but others are not. And thus the output isn't all that useful. It is possible it's due to a legit bug - in which case rendering might be wrong however it still should not cause segfaults (and I didn't see that with this replay, just bogus rendering). FWIW the trace has some issues, namely it requests a 4.5 context thus needs overrides to run. Not sure if this actually causes problems. I actually tried to give the replay a look, but the problem is that so far I've always failed to get apitrace + valgrind + gdb to work. The problem is I can't get into gdb on errors on forked processes. valgrind --trace-children=yes works fine, but if you use that with --vgdb=yes --vgdb-error=0 what happens is this works on first (useless) process just fine. However, valgrind will ask to attach a second gdb on the fork, which immediately claims remote connection closed after the "target remote..." command. It will actually ask again after that happens, but if you retry it gdb just complains it can't access memory at some addresses and that's it - on errors valgrind just waits on that gdb connection which doesn't exist... If someone knows if and how this is somehow supposed to work that would be helpful... I think this actually used to work with the --db-enable option but this one is gone for good now.</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>