<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - GLX_INTEL_swap_event crashes driver when swapping window buffers"
href="https://bugs.freedesktop.org/show_bug.cgi?id=54372#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - GLX_INTEL_swap_event crashes driver when swapping window buffers"
href="https://bugs.freedesktop.org/show_bug.cgi?id=54372">bug 54372</a>
from <span class="vcard"><a class="email" href="mailto:danmanj@gmail.com" title="danmanj@gmail.com">danmanj@gmail.com</a>
</span></b>
<pre>Attached is a backtrace from the crash with the 10.1.4 glx libs.
The same patch attached here still fixes the crash.
It would take me days to produce a small test program for you. My program is
quite complex.
Let me give you my take on what is happening <plus 2 years of foggy memmory>.
A bufferswap event has been generated and the app process has received it.
DRI2 WireToEvent is supposed to translate the serialized event into a
memory-resident XEvent struct.
DRI2WireToEvent looks for a GLX Drawable that matches the input event with
GetGLXDrawable. It needs to do this just in case there has been an overflow in
the swap count to do basic ccounting <apparently>.
UNEXPECTEDLY GetGLXDrawable returns NULL. This is allowed. If somebody sends
you a bogus XEvent you SHOULD NOT CRASH.
DRI2WireToEvent doesn't bother checking if the pointer is NULL. Dereferences
it, and CRASH occurs.
My opinion: Even if you decide there is a separate bug causing the NULL return
you still need this patch. As things stand, any random delayed XEvent can crash
any glx program.</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>