That commit 99a2cf1aa was moving the calls to the _Xcms*CmapRec*()
family of functions within a display lock to make the XCMS colormap
functions thread safe.
Unfortunately, that causes a deadlock in XCopyColormapAndFree(), because
_XcmsCopyCmapRecAndFree() calls CmapRecForColormap() which calls
XGetVisualInfo() which also tries to acquire the display lock.
So, instead of moving the entire functions within the display lock,
let's try to make the functions themselves thread safe in the following
commit, and revert this change which causes a deadlock.
This reverts commit 99a2cf1aa0.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/215
See-also: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/94
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>
XCopyColormapAndFree/5 threw an assertion:
520|4 5 00014017 1 2|Assertion XCopyColormapAndFree-5.(A)
520|4 5 00014017 1 3|When a colourmap argument does not name a valid colourmap,
520|4 5 00014017 1 4|then a BadColor error occurs.
520|4 5 00014017 1 5|METH: Create a bad colourmap by creating and freeing a colourmap.
520|4 5 00014017 1 6|METH: Call test function using bad colourmap as the colourmap argument.
520|4 5 00014017 1 7|METH: Verify that a BadColor error occurs.
520|4 5 00014017 1 8|unexpected signal 6 (SIGABRT) received
220|4 5 2 15:05:53|UNRESOLVED
410|4 5 1 15:05:53|IC End
510|4|system 0: Abandoning testset: caught unexpected signal 11 (SIGSEGV)
More specifically:
lt-XCopyColormapAndFree: xcb_io.c:533: _XAllocID: Assertion `ret != inval_id' failed.
This bug was introduced (by following my advice, d'oh) in:
commit 99a2cf1aa0
Author: Tapani Pälli <tapani.palli@intel.com>
Date: Mon May 13 08:29:49 2019 +0300
Protect colormap add/removal with display lock
In that patch we moved the call to _XcmsCopyCmapRecAndFree inside the
display lock. The problem is said routine has side effects, including
trying to implicitly create a colormap in some cases. Since we don't run
the XID handler until SyncHandle() we would see inconsistent internal
xlib state, triggering the above assert.
Fix this by dropping and re-taking the display lock before calling into
XCMS.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
This fixes a bug where concurrent threads call XCreateColormap and
XFreeColormap corrupting a linked list where colormap structures
are stored.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/94
v2: handle XCopyColormapAndFree also (Adam Jackson)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
- For Xcomposite and Xdamage, don't link the build system out of the xc tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source
