Skip to content

wayland: avoid stale wl_buffer destroy after unmatched release#2102

Open
awsms wants to merge 1 commit intoValveSoftware:masterfrom
awsms:fix/wayland-stale-wl-buffer-destroy
Open

wayland: avoid stale wl_buffer destroy after unmatched release#2102
awsms wants to merge 1 commit intoValveSoftware:masterfrom
awsms:fix/wayland-stale-wl-buffer-destroy

Conversation

@awsms
Copy link

@awsms awsms commented Mar 6, 2026

Some compositors (observed on Hyprland) can send wl_buffer.release for a buffer that gamescope never marked as compositor-acquired, which puts the buffer into a release-without-acquire state. In that state, sending wl_buffer.destroy later can target a stale server-side object id and trigger a protocol error (e.g. "invalid object 49"), aborting nested --backend wayland sessions.

Track this release-without-acquire condition in CWaylandFb and, in that case, destroy only the local proxy with wl_proxy_destroy instead of emitting wl_buffer.destroy.
Normal buffers keep the existing wl_buffer_destroy path.

edit: can't find the issue number anymore, but this fixes --backend wayland being completely unusable on some setups, and forcing the use of --backend sdl.

Some compositors (observed on Hyprland) can send `wl_buffer.release`
for a buffer that gamescope never marked as compositor-acquired, which
puts the buffer into a release-without-acquire state.
In that state, sending `wl_buffer.destroy` later can target
a stale server-side object id and trigger a protocol error
(e.g. "invalid object 49"), aborting nested `--backend wayland` sessions.

Track this release-without-acquire condition in CWaylandFb and,
in that case, destroy only the local proxy with `wl_proxy_destroy`
instead of emitting `wl_buffer.destroy`.
Normal buffers keep the existing `wl_buffer_destroy` path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant