-
Adam Jackson authored
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 99a2cf1a 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>
68c72a73