Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • wayland wayland
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 117
    • Issues 117
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • waylandwayland
  • Issues
  • #10
Closed
Open
Created Mar 10, 2017 by Bugzilla Migration User@bugzilla-migration

Adding/removing temporary globals is racy

Submitted by Jonas Ådahl @jadahl

Assigned to Jonas Ådahl @jadahl

Link to original bug (#7722)

Description

Adding and then removing a global object via wl_registry is racy, as after the client responds with a wl_registry.bind to the 'add', when the compositor sees the bind request, the global might already have been destroyed, causing the client to be terminated with an error. This is an known and old issue; this task is created in order to document the existence, track any progress and/or document best practices.

The major issue is that the client currently have no way to detect this, and a compliant client may be terminated without a warning. It's currently causing issues with fast monitor hotplugs in mutter, where a wl_output is already gone compositor side when receiving a clients bind request.

A compositor can mitigate this unreliably by artificially delay the removal until clients have had "enough" time to bind the global. The amount of time needed will not be known, and this mitigation is not a guarantee that the race won't happen. During this time, the compositor would have to deal with requests to these inert objects, or requests where the inert object is passed as an argument, including creating new objects from it (i.e. more inert objects).

A change to libwayland-server might be desirable, to at least add support for deleting a global immediately, while still being able to deal with bind requests to these deleted globals.

Previous RFC related to this issue, AFAIK without any documented conclusion:
https://lists.freedesktop.org/archives/wayland-devel/2015-February/020273.html

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking