From 5096fcd492b1efd178773748e5f42177439426d6 Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax@redhat.com>
Date: Wed, 14 Aug 2019 14:10:07 -0400
Subject: [PATCH] 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@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@entry=0) at resource.c:910
    #13 0x000000000051ee01 in compUnredirectWindow (pClient=0x1f6b4e0, pWin=pWin@entry=0x28489c0, update=update@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@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@entry=0) at resource.c:880
    #23 0x0000000000598b0c in FreeClientResources (client=client@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.
---
 composite/compalloc.c | 2 ++
 1 file changed, 2 insertions(+)

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