<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c" href="https://bugs.freedesktop.org/show_bug.cgi?id=98883#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c" href="https://bugs.freedesktop.org/show_bug.cgi?id=98883">bug 98883</a> from <a class="email" href="mailto:psychon@znc.in" title="Uli Schlachter <psychon@znc.in>"> Uli Schlachter</a> <pre>@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 <a href="show_bug.cgi?id=98883#c3">comment #3</a> 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 <a href="show_bug.cgi?id=98883#c6">comment #6</a> says it is about <a href="https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252">https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252</a> instead of this bug. <a href="https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252">https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751252</a> 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>