libX11: Changes to 'master'

[GitLab Mirror]

 src/CopyCmap.c |    5 +++++
 1 file changed, 5 insertions(+)

New commits:
commit 68c72a7341b114277ab232f2499ee3bd035af8a0
Author: Adam Jackson <ajax at redhat.com>
Date:   Wed Dec 11 11:53:11 2019 -0500

    Fix XTS regression in XCopyColormapAndFree
    
    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 99a2cf1aa0b58391078d5d3edf0a7dab18c7745d
        Author: Tapani Pälli <tapani.palli at 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 at intel.com>