Commit 5096fcd4 authored by Adam Jackson's avatar Adam Jackson 🎧 Committed by Adam Jackson
Browse files

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>, ccw...
parent 3c78d637
......@@ -97,6 +97,8 @@ compDestroyDamage(DamagePtr pDamage, void *closure)
CompWindowPtr cw = GetCompWindow(pWin);
cw->damage = 0;
cw->damaged = 0;
cw->damageRegistered = 0;
}
static Bool
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment