Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wayland-deadlock #2

Merged
merged 2 commits into from
Jan 2, 2025
Merged

wayland-deadlock #2

merged 2 commits into from
Jan 2, 2025

Conversation

Adjective-Object
Copy link
Owner

Fork-local copy of not-fl3#508

Currently, if a game using the linux_wayland backend loses focus, it
will deadlock with the following stack:

```
(gdb) bt
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
... (omitted for brevity)
    at src/lib.rs:506
    data=0x7ffc4e5c5fb0, _toplevel=0x558428e38e40, width=800, height=600, _states=0x5584298b6770)
    at src/native/linux_wayland.rs:508
...
   from /lib/x86_64-linux-gnu/libwayland-client.so.0
...
```

What's happening here is that the wayland backend is holding onto the
mutex guard for the `native_display()` when it dispatches the resize
event to event listeners.

This hits the `EventHandler` impl for `Stage` in macroquad 0.4.13, which
attempts to re-lock the `native_display()` while it is already locked by
the wayland backend
https://docs.rs/crate/macroquad/0.4.13/source/src/lib.rs#506

The fix here is to guarantee that the native display is released before
dispatching events.
This looks like it was already done for the `payload.decorations`
codepath, but not for the event handlers. I can't see a motivation for
continuing to hold the lock past where we read the last data off the
display, so I've simply moved the manual drop up to always execute.
@Adjective-Object Adjective-Object changed the title Wayland deadlock wayland-deadlock Jan 2, 2025
@Adjective-Object Adjective-Object merged commit dbfb2ed into master Jan 2, 2025
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