bug#56967: 29.0.50; Frequent crashes under Wayland

[Bjoern Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Am Freitag, 5. August 2022, 09:29:47 EEST schrieb Po Lu:
> [*Please* use "Reply All" to reply, otherwise your response will not be
> recorded on the bug tracker]
> 
> Bjoern Bidar <bjorn.bidar@thaodan.de> writes:
> > That's the thing it doesn't look like the connection is unstabl alos
> > nothing else but Emacs has this issue.
> 
> Did you leave anything else up for long enough? Try keeping gtk3-demo up
> for a similar amount of time.

I did I had my hole session running, nothing else had that issue.
I kept the GTK-Demo running nothing happened it ran just fine.

After a few hours Emacs exited with the same behaviour as explained in the 
bug.

I on the #gtk channel on what do and I got from ebassi that it is ok to just 
call _exit.
He says it might be the client behaving wrong:
<ebassi> Thaodan: It could happen because the client made an invalid request—
Wayland mandates that the display server closes the connection in that case

I don't really understand why calling _exit is an acceptable solution anyone 
that has to safe some state to the disk is lost.

I attach the whole conversation to not take anything out of context here:
<Thaodan> Hello why does GTK call _exit when a display connection is lost in 
wayland, how can the app react to  loosing the display connection?
<Thaodan> I noticed that Emacs sometimes looses the display connection under 
Wayland (not XWayland).
<ebassi> You don't
<ebassi> If a client loses the connection to a running compositor then it's 
generally a bug in the client
<ebassi> If you lose the connection to the display server all hope is 
generally lost
<Thaodan> ebassi: An app may run longer or before the compositor starts even 
if not it's not nice as an application to just quit and not even let the 
application clean up after it self.
<ebassi> In theory, under Wayland, it might be possible to clean all data 
attached to the display, but it's unlikely this will ever work without 
applications dealing with it
<ebassi> And if you lose the socket then you'
<ebassi> you'll have to find the new one and reconnect
<ebassi> Thaodan: Only emacs does that
<ebassi> Pretty much literally
<Thaodan> "that"?
<ebassi> "app may run longer or before the compositor starts"
<ebassi> Because emacs is really a 1980s teletype app
<Thaodan> What does that change? calling _exit is not a solution.
<Thaodan> Lets assume the fault for this happening is emacs, what could cause 
this?
<ebassi> Calling exit is perfectly acceptable: the display connection is 
severed, and that can happen for multiple reasons, including the display 
server going away
<ebassi> There's no "the display server is still running, but it closed the 
socket" mechanism for the toolkit to use
<ebassi> The socket got closed
<ebassi> The toolkit terminates
<ebassi> Thaodan: It could happen because the client made an invalid request—
Wayland mandates that the display server closes the connection in that case
<ebassi> Or the display server decided to kill the client because it was 
unresponsive
<Thaodan> Why should the toolkit/lib call exit isn't there any better 
mechanism to doing such a thing in glib or gtk for that matter? 
<Thaodan> It would be better to not need any hacks to prevent gtk from killing 
apps.
<ebassi> Thaodan: There is no such mechanism
<Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, 
doesn't that break any other app that has state so safe too? like for example 
an office application that wants to safe it's data before going down.
<ebassi> I already told you
<ebassi> If the display connection is closed by the server, then there's no 
safe way to store the data