[cairo-bugs] [Bug 98883] BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98883

--- Comment #8 from Uli Schlachter <psychon at znc.in> ---
@Sebastian: I don't know who you count as a maintainer, but I'll take a look...

So... this bug is about _cairo_xlib_shm_pool_create() getting the sequence
number for pool->attached wrong, resulting in cairo possibly destroying the
shared memory segment to early. The discussion concluded that setting
pool->attached = XNextRequest(dpy)-1 after the request is the right fix.
In comment #3 I wondered about XLockDisplay(), but that seems unrelated. I was
possibly confused since there are two places calling XShmAttach() and one of
them locks the display while the other one does not.

The patch in comment #6 says it is about
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252 instead of this
bug. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252 must be a
different bug since it also happens with GDK_SYNCHRONIZE=1, which means that
the race that this bug is about cannot happen.

What the patch does is to make XShmAttach synchronous (aka "slow"). I do not
know why, but nothing in this bug report suggests that this is necessary. The
description of the patch does not say anything about this either. XShmAttach()
should not just randomly fail, so why does the patch try to handle random
failures?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20180725/b42bcf4d/attachment.html>