[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56967: 29.0.50; Frequent crashes under Wayland
From: |
Bjoern Bidar |
Subject: |
bug#56967: 29.0.50; Frequent crashes under Wayland |
Date: |
Sun, 07 Aug 2022 17:51:25 +0300 |
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
- bug#56967: 29.0.50; Frequent crashes under Wayland, (continued)
- bug#56967: 29.0.50; Frequent crashes under Wayland, Eli Zaretskii, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Eli Zaretskii, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Gregory Heytings, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland, Eli Zaretskii, 2022/08/05
- Message not available
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/05
- bug#56967: 29.0.50; Frequent crashes under Wayland,
Bjoern Bidar <=
- bug#56967: 29.0.50; Frequent crashes under Wayland, Eli Zaretskii, 2022/08/07
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/07
- bug#56967: 29.0.50; Frequent crashes under Wayland, Eli Zaretskii, 2022/08/07
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/07
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/07
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/08
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/08
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/08
- bug#56967: 29.0.50; Frequent crashes under Wayland, Bjoern Bidar, 2022/08/05
- Message not available
- bug#56967: 29.0.50; Frequent crashes under Wayland, Po Lu, 2022/08/05