[Mesa-dev] [Bug 54372] GLX_INTEL_swap_event crashes driver when swapping window buffers

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Jun 7 20:37:54 PDT 2014


danmanj at gmail.com changed:

           What    |Removed                     |Added
             Status|NEEDINFO                    |NEW

--- Comment #12 from danmanj at gmail.com ---
Ok, I have spent another day looking into all this. I am more confident than
before that this patch is _EXACTLY_ correct. Let me break it down for

Prior to GLX 1.3 there was the glxMakeCurrent() function that took a single
drawable handle. The Drawable could be either a bare XID for a Window or an XID
for a glxpixmap.

GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for reading, one
for writing. Nowadays the old glxMakeCurrent call is implemented as a call to
glxMakeContextCurrent with the single handle duplicated.

Because of this it is allowed to use a plain-old Window ID as an argument to
glxMakeContextCurrent, although nobody really documents this sort of thing. The
manpage for the NEW call specifies the arguments as GLXPixmaps, but the actual
code accepts Window XIDs too, and handles them correctly.

Similarly, the glxSelectEvents function can also take a bare Window XID.

The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never tested swap
events with a bare Window XID. That is what my app was doing.

The swap_events code worked with Window XIDs in mesa 7.x.y. The new code added
in versions 8, 9, and 10 assumes that all buffer swap events have a GLXPixmap
associated with them. Because of the historical quirks above THIS IS NOT TRUE.
Swap events for bare Window XIDs do NOT have a glxpixmap.

I repeat ____THIS IS NOT TRUE____. It will crash.

So... any app that uses the old school glxMakeCurrent call with a Window XID
while trying to use swap_events will crash when the libs try to lookup the
nonexistent GLXPixmap associated with the incoming swap event.

I believe that the people who wrote the spec overlooked this, because the "sbc"
field comes from the OML_sync extension that is defined in terms of glxpixmaps

Regardless... The only reason that the library is looking up the glxpixmap is
to handle counter overflows nicely. I can tell you that nobody cares about
that. If the choice is a crash or handling counter wraps manually I'll take
counter manual wraps.

Please just apply the patch already and update the spec to say counter wraps
only work nicely with glxpixmaps.

I can work around this bug by creating glxpixmaps instead of using a raw Window
XID for my main window. But you're still stuck having to handle this case. I've
thought deeply about your options, and my patch is the least painful.

I could write more but I'm hoping that you are convinced by now.

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140608/85fbdbd4/attachment.html>

More information about the mesa-dev mailing list