|
 |
4b168a |
From a515545065ce6e1924de4bc50aaae7ec9b48cfad Mon Sep 17 00:00:00 2001
|
|
|
4b168a |
From: Adam Jackson <ajax@redhat.com>
|
|
|
4b168a |
Date: Wed, 11 Dec 2019 11:53:11 -0500
|
|
|
4b168a |
Subject: [PATCH libX11] Fix XTS regression in XCopyColormapAndFree
|
|
|
4b168a |
MIME-Version: 1.0
|
|
|
4b168a |
Content-Type: text/plain; charset=UTF-8
|
|
|
4b168a |
Content-Transfer-Encoding: 8bit
|
|
|
4b168a |
|
|
|
4b168a |
XCopyColormapAndFree/5 threw an assertion:
|
|
|
4b168a |
|
|
|
4b168a |
520|4 5 00014017 1 2|Assertion XCopyColormapAndFree-5.(A)
|
|
|
4b168a |
520|4 5 00014017 1 3|When a colourmap argument does not name a valid colourmap,
|
|
|
4b168a |
520|4 5 00014017 1 4|then a BadColor error occurs.
|
|
|
4b168a |
520|4 5 00014017 1 5|METH: Create a bad colourmap by creating and freeing a colourmap.
|
|
|
4b168a |
520|4 5 00014017 1 6|METH: Call test function using bad colourmap as the colourmap argument.
|
|
|
4b168a |
520|4 5 00014017 1 7|METH: Verify that a BadColor error occurs.
|
|
|
4b168a |
520|4 5 00014017 1 8|unexpected signal 6 (SIGABRT) received
|
|
|
4b168a |
220|4 5 2 15:05:53|UNRESOLVED
|
|
|
4b168a |
410|4 5 1 15:05:53|IC End
|
|
|
4b168a |
510|4|system 0: Abandoning testset: caught unexpected signal 11 (SIGSEGV)
|
|
|
4b168a |
|
|
|
4b168a |
More specifically:
|
|
|
4b168a |
|
|
|
4b168a |
lt-XCopyColormapAndFree: xcb_io.c:533: _XAllocID: Assertion `ret != inval_id' failed.
|
|
|
4b168a |
|
|
|
4b168a |
This bug was introduced (by following my advice, d'oh) in:
|
|
|
4b168a |
|
|
|
4b168a |
commit 99a2cf1aa0b58391078d5d3edf0a7dab18c7745d
|
|
|
4b168a |
Author: Tapani Pälli <tapani.palli@intel.com>
|
|
|
4b168a |
Date: Mon May 13 08:29:49 2019 +0300
|
|
|
4b168a |
|
|
|
4b168a |
Protect colormap add/removal with display lock
|
|
|
4b168a |
|
|
|
4b168a |
In that patch we moved the call to _XcmsCopyCmapRecAndFree inside the
|
|
|
4b168a |
display lock. The problem is said routine has side effects, including
|
|
|
4b168a |
trying to implicitly create a colormap in some cases. Since we don't run
|
|
|
4b168a |
the XID handler until SyncHandle() we would see inconsistent internal
|
|
|
4b168a |
xlib state, triggering the above assert.
|
|
|
4b168a |
|
|
|
4b168a |
Fix this by dropping and re-taking the display lock before calling into
|
|
|
4b168a |
XCMS.
|
|
|
4b168a |
---
|
|
|
4b168a |
src/CopyCmap.c | 5 +++++
|
|
|
4b168a |
1 file changed, 5 insertions(+)
|
|
|
4b168a |
|
|
|
4b168a |
diff --git a/src/CopyCmap.c b/src/CopyCmap.c
|
|
|
4b168a |
index b4954b01..b37aba73 100644
|
|
|
4b168a |
--- a/src/CopyCmap.c
|
|
|
4b168a |
+++ b/src/CopyCmap.c
|
|
|
4b168a |
@@ -53,6 +53,11 @@ Colormap XCopyColormapAndFree(
|
|
|
4b168a |
mid = req->mid = XAllocID(dpy);
|
|
|
4b168a |
req->srcCmap = src_cmap;
|
|
|
4b168a |
|
|
|
4b168a |
+ /* re-lock the display to keep XID handling in sync */
|
|
|
4b168a |
+ UnlockDisplay(dpy);
|
|
|
4b168a |
+ SyncHandle();
|
|
|
4b168a |
+ LockDisplay(dpy);
|
|
|
4b168a |
+
|
|
|
4b168a |
#if XCMS
|
|
|
4b168a |
_XcmsCopyCmapRecAndFree(dpy, src_cmap, mid);
|
|
|
4b168a |
#endif
|
|
|
4b168a |
--
|
|
|
4b168a |
2.23.0
|
|
|
4b168a |
|