[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 #4 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Roland Scheidegger from comment #2)
> > > ==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.

-- 
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/20160416/1665f0b4/attachment.html>