We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4689 - SDL fails to detect compositor shutdown on Wayland -- program keeps running
Summary: SDL fails to detect compositor shutdown on Wayland -- program keeps running
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 minor
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2019-06-23 02:22 UTC by M Stoeckl
Modified: 2019-09-20 20:48 UTC (History)
0 users

See Also:

Attachments
A diff which worksforme to resolve the issue (749 bytes, patch)
2019-06-23 02:22 UTC, M Stoeckl 		Details | Diff
Updated patch to fix the issue (2.01 KB, patch)
2019-08-04 02:02 UTC, M Stoeckl 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description M Stoeckl 2019-06-23 02:22:58 UTC 
Created attachment 3841 [details]
A diff which worksforme to resolve the issue

To reproduce:

1. Run any SDL-based program with a Wayland compositor, orphaning it so that it doesn't have an immediate parent process. (For example, from a terminal, running `supertux2 & disown`.) The program should use the wayland backend, i.e. by setting environment variable SDL_VIDEODRIVER=wayland.
2. Kill the compositor process.

Results:

- The SDL program will keep running.

Expected results:

- The SDL program should close. (What close should mean here, I'm not sure - is injecting an SDL_Quit the appropriate action when a video driver disconnects?)

Build data:

2019-06-22, hg tip (12901:5cbf6472a916), Linux, can reproduce with sway, weston, and other Wayland oompositors.

Additional information:

I've attached a diff which quits when the Wayland connection encounters an error. It solves the problem for me, since when the connection closes, eventually wl_display_dispatch will be called and fail. But there are other possible variations on the patch: use poll to check for POLLHUP on the connection fd or also quit when wl_display_dispatch_pending fails.
Comment 1 Ryan C. Gordon 2019-07-30 17:49:36 UTC 
(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.
Comment 2 M Stoeckl 2019-08-04 02:02:09 UTC 
Created attachment 3920 [details]
Updated patch to fix the issue

This patch only sends the quit event once, because some existing applications (SuperTux, some recent git version) appear to check for events after receiving a quit message, causing an infinite loop.
Comment 3 Sam Lantinga 2019-08-06 06:39:30 UTC 
Patch added, thanks!
https://hg.libsdl.org/SDL/rev/e6407f3ddba3
Comment 4 Ryan C. Gordon 2019-09-20 20:47:36 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 5 Ryan C. Gordon 2019-09-20 20:48:42 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.