Commit 5096fcd4 authored byBrowse 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...
Showing with 2 additions and 0 deletions