<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> <span class="fn">Roland Scheidegger</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94955">bug 94955</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94955#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94955">bug 94955</a>
from <span class="vcard"><a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> <span class="fn">Roland Scheidegger</span></a>
</span></b>
<pre>(In reply to Roland Scheidegger from <a href="show_bug.cgi?id=94955#c5">comment #5</a>)
<span class="quote">> (In reply to Roland Scheidegger from <a href="show_bug.cgi?id=94955#c4">comment #4</a>)
> > 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.
> Forget this it actually works. I'll see if I can find what caused this
> specific complaint, but I wouldn't count on it this being the real problem.</span >
So, I've tracked this down a bit - the jne instruction where valgrind complains
is actually the result of a ptest instruction. This is due to
lp_build_mask_check() which tests if not all pixels have been killed (if they
have, it would skip execution of the rest of the shader).
This "pixel alive" mask is always initialized fully, so initially not undefined
(the plane evaluation generated this essentially figuring out which pixels in a
2x2 pixel quad belong to the current triangle).
BUT, the shader does something along the lines of:
IF whatever
temp0.x = something
ENDIF
KILL_IF temp0.x
Interestingly, we actually do zero-intialize all temp regs, thus things still
have to be defined, even if that temp0.x assignment didn't assign all channels
according to the exec mask. The kill_if will then combine the pixel alive mask
with the mask generated from temp0.x < 0 comparison, then do the
lp_build_mask_check() using this mask which triggers the warning.
Ultimately, I do not really know why valgrind thinks it's undefined. However,
to my knowledge valgrind can track definedness of values at a bit level (which
is quite an amazing feat indeed), but NOT for sse regs. There's some warnings
it might be less accurate there.
(FWIW --track-origins=yes simply points to lp_rast_arg_triangle_contained
(lp_rast.h:220))
Theoretically, of course it is also possible the undefinedness directly comes
from a buggy application itself (think something simple like glUniform call
using an undefined value in the first place).
But I've seen this warning so many times and everything still worked that I do
not believe valgrind complaints which are directed toward mask checks point to
any real problem (and I have doubts they are even valid).
So, I'm going to mark this bug as fixed. Two minor issues have been addressed
(well actually the fb one could have real consequences resulting in unnecessary
state updates), and I'm not seeing any random segfaults in any case. Even if
valgrind is right about the uninitialized values in the jit code that won't
cause crashes (valgrind would say invalid read/write for anything which could
crash). Feel free to open a new bug if you see crashes (preferably with a
backtrace) or misrenderings.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>