xserver: Branch 'master'

[GitLab Mirror]

 composite/compalloc.c |    2 ++
 1 file changed, 2 insertions(+)

New commits:
commit 5096fcd492b1efd178773748e5f42177439426d6
Author: Adam Jackson <ajax at redhat.com>
Date:   Wed Aug 14 14:10:07 2019 -0400

    composite: Be more paranoid in compDestroyDamage
    
    Consider these two facts:
    
    - You can't rely on resource deletion order
    - damageDestroyWindow automatically destroys any damage listener
      connected to the doomed window
    
    Now consider a redirected window being destroyed. If the damage
    associated with the redirection is destroyed before the window, then
    when compFreeClientWindow tries to unredirect the window, the call to
    compSetParentPixmap may see that cw->damageRegistered is still true, and
    call DamageUnregister(NULL) (because compDestroyDamage already zeroed
    out cw->damage), and you get a backtrace that looks like:
    
        #6  <signal handler called>
        #7  DamageUnregister (pDamage=0x0) at damage.c:1773   <-----------------
        #8  0x000000000051f767 in compSetParentPixmap (pWin=pWin at entry=0x28489c0) at compalloc.c:646
        #9  0x000000000051fa01 in compFreeClientWindow (pWin=0x28489c0, id=<optimized out>) at compalloc.c:291
        #10 0x000000000051a499 in FreeCompositeClientWindow (value=<optimized out>, ccwid=<optimized out>) at compext.c:74
        #11 0x0000000000597932 in doFreeResource (res=0x28494c0, skip=0) at resource.c:880
        #12 0x000000000059850e in FreeResource (id=857, skipDeleteFuncType=skipDeleteFuncType at entry=0) at resource.c:910
        #13 0x000000000051ee01 in compUnredirectWindow (pClient=0x1f6b4e0, pWin=pWin at entry=0x28489c0, update=update at entry=0) at compalloc.c:336
        #14 0x000000000051b723 in compCheckBackingStore (pWin=0x28489c0) at compinit.c:131
        #15 compChangeWindowAttributes (pWin=0x28489c0, mask=<optimized out>) at compinit.c:152
        #16 0x000000000051d1f9 in compDestroyWindow (pWin=0x28489c0) at compwindow.c:664
        #17 0x00000000004d85be in damageDestroyWindow (pWindow=0x28489c0) at damage.c:1570
        #18 0x00000000004896f0 in DbeDestroyWindow (pWin=0x28489c0) at dbe.c:1326
        #19 0x00000000004d229e in present_destroy_window (window=0x28489c0) at present_screen.c:163
        #20 0x000000000059c4e4 in FreeWindowResources (pWin=pWin at entry=0x28489c0) at window.c:1032
        #21 0x000000000059f2c6 in DeleteWindow (value=0x28489c0, wid=<optimized out>) at window.c:1101
        #22 0x0000000000597932 in doFreeResource (res=0x2843bd0, skip=skip at entry=0) at resource.c:880
        #23 0x0000000000598b0c in FreeClientResources (client=client at entry=0x2848560) at resource.c:1146
        #24 0x0000000000572e2f in CloseDownClient (client=0x2848560) at dispatch.c:3473
    
    Fix this by zeroing out more of the CompWindowPtr when the damage is
    destroyed, so that any further calls into composite will avoid touching
    cw->damage.

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 23320c406..eaabf0d91 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -97,6 +97,8 @@ compDestroyDamage(DamagePtr pDamage, void *closure)
     CompWindowPtr cw = GetCompWindow(pWin);
 
     cw->damage = 0;
+    cw->damaged = 0;
+    cw->damageRegistered = 0;
 }
 
 static Bool