<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - memory leak with intel i965 mesa when running android container in Ubuntu"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104884#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - memory leak with intel i965 mesa when running android container in Ubuntu"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104884">bug 104884</a>
from <span class="vcard"><a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> <span class="fn">Eero Tamminen</span></a>
</span></b>
<pre>(In reply to Kenneth Graunke from <a href="show_bug.cgi?id=104884#c15">comment #15</a>)
<span class="quote">> (In reply to Jiancong from <a href="show_bug.cgi?id=104884#c14">comment #14</a>)
> > Testing with Simon's patch,removing ralloc_strdup, it still be found
> > following possible leaking points.</span >
...
<span class="quote">> That happens when you forget to glXDestroyContext and glXMakeCurrent to NULL
> to unbind it so it can actually get freed. It's not a driver bug.</span >
(In reply to Jiancong from <a href="show_bug.cgi?id=104884#c16">comment #16</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=137522" name="attach_137522" title="Patched with previous fix, and rerun the valgrind memcheck.">attachment 137522</a> <a href="attachment.cgi?id=137522&action=edit" title="Patched with previous fix, and rerun the valgrind memcheck.">[details]</a></span>
> Patched with previous fix, and rerun the valgrind memcheck.</span >
Please fix the issue pointed out by Kenneth first, and some of the other
application bugs visible in the valgrind output first. Otherwise it's hard to
say which of those numerous items in your log are relevant.
Alternative, you could kill the valgrind process with a signal that the
application doesn't catch, but Valgrind can catch (e.g. SIGHUP or SIGXCPU could
be such). That way application cannot mess up the leakage info with bugs it
has in its exit path (which are irrelevant for tracking down run-time leakage).
Note that for tracking down larger leaks, Valgrind Massif output is often more
useful than Valgrind Memcheck output.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>