all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bjoern Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: 56967@debbugs.gnu.org
Subject: bug#56967: 29.0.50; Frequent crashes under Wayland
Date: Sun, 07 Aug 2022 17:51:25 +0300	[thread overview]
Message-ID: <20004002.VVDfsmh7uS@odin> (raw)
In-Reply-To: <87fsib9p9g.fsf@yahoo.com>

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







  reply	other threads:[~2022-08-07 14:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04  7:36 bug#56967: 29.0.50; Frequent crashes under Wayland Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-04  8:01 ` Eli Zaretskii
     [not found]   ` <3230275.qDoO4GC8Cx@odin>
2022-08-04  8:21     ` Eli Zaretskii
2022-08-04 11:49       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  0:18         ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  0:50           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:25             ` Eli Zaretskii
2022-08-05  6:28               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:43                 ` Eli Zaretskii
2022-08-05  6:53                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  7:46                     ` Eli Zaretskii
2022-08-05  8:26                       ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  8:38                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:56                 ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:59                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05 11:40               ` Gregory Heytings
2022-08-05 11:50                 ` Eli Zaretskii
     [not found]             ` <2972937.jrzt3BHeHG@odin>
2022-08-05  6:29               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07 14:51                 ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-08-07 15:07                   ` Eli Zaretskii
2022-08-07 15:14                     ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07 15:44                       ` Eli Zaretskii
2022-08-08  2:42                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-08  2:40                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-08  6:07                     ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-08  8:56                     ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-08 10:10                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 12:10                       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 12:10                       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 13:11                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 17:06                           ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:31             ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]             ` <2189728.upBv5HjrgE@odin>
2022-08-05  6:31               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]             ` <1917872.q2Y8mqo1ke@odin>
2022-08-05  6:35               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  6:55                 ` Bjoern Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-05  7:01                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-17 16:02 ` Gavin Massingham
     [not found] <CAH3b6=SPM_Pys81fi-_Eu=VXO8mETqV+s0YFC+8c1huv4dmh9Q@mail.gmail.com>
2022-08-04 18:29 ` Eli Zaretskii
2022-08-05  7:34   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20004002.VVDfsmh7uS@odin \
    --to=bug-gnu-emacs@gnu.org \
    --cc=56967@debbugs.gnu.org \
    --cc=bjorn.bidar@thaodan.de \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.