Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
xserver
xserver
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 889
    • Issues 889
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 95
    • Merge Requests 95
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • xorg
  • xserverxserver
  • Merge Requests
  • !261

Merged
Opened Aug 14, 2019 by Adam Jackson@ajax💣Owner

composite: Be more paranoid in compDestroyDamage

  • Overview 1
  • Commits 1
  • Pipelines 2
  • Changes 1

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.

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Reference: xorg/xserver!261
Source branch: damage-paranoia