Making Emacs popular again

Posted May 6, 2020 23:56 UTC (Wed) by ms-tg (subscriber, #89231)
Parent article: Making Emacs popular again

Following the trail of the 17 year old GTK+ bug to their new Gitlab-based tracker led me to an assertion made just 8 months ago that this is “ridiculous”, there is no evidence of a bug, but a vestigial call to abort() within emacs for historical reasons:
https://gitlab.gnome.org/GNOME/gtk/issues/221#note_577021

Can anyone clarify if this is accurate?

Making Emacs popular again

Posted May 7, 2020 1:45 UTC (Thu) by mohg (guest, #114025) [Link] (11 responses)

I don't think that's quite the situation.

I think that, although this abort was originally added to Emacs because of a GTK+ issue, in recent years other issues have been triggering the same abort. For example, the comments about Emacs aborting when certain unicode characters are inserted relate to a different problem. I can sympathize with GTK developers getting frustrated when people add unrelated Emacs crashes to their bug reports.

I can also sympathize with them wanting a minimal test case. Looks like someone provided one at
https://gitlab.gnome.org/GNOME/gtk/-/issues/2315
to which the response was "Surviving a display connection going away is basically uninteresting for anything but emacs, so the chances of this getting fixed and keeping working are somewhat low.". Fair enough.

I'm not sure it's helpful for Emacs to print another project's bug URL in its abort message. Perhaps the comment should be removed, especially since other things can trigger it.

Making Emacs popular again

Posted May 7, 2020 2:12 UTC (Thu) by pabs (subscriber, #43278) [Link] (10 responses)

Surviving a display connection going away is exceptionally interesting since GNOME shell crashes so often, it would be awesome to be able to keep apps running in the background and have them reconnect when the session returns. Even if GNOME shell or your favourite window manager is not crashy, it is useful to be able to restart GNOME shell after upgrades without having to restart apps.

Making Emacs popular again

Posted May 7, 2020 7:54 UTC (Thu) by mina86 (guest, #68442) [Link] (9 responses)

Window manager crashing does not affect if other applications loose connection to the server. Or am I missing something?

Making Emacs popular again

Posted May 7, 2020 8:21 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (8 responses)

Wayland… on wayland Gnome isn't only the wm, it's replacing Xorg too. When it crashes it kills the entire session.

I've had that happen to me on Fedora by downloading a .iso in /tmp. Fedora mounts /tmp on tmpfs, so the RAM got filled, so the OOMKiller triggered and killed gnome and everything I had open along with it.

Making Emacs popular again

Posted May 7, 2020 12:40 UTC (Thu) by ebassi (subscriber, #54855) [Link] (7 responses)

When it crashes it kills the entire session.

Just like when the X server crashes, as the compositor in Wayland is also the display server.

Ideally, we GTK developers would like to allow clients to survive a display connection closure—and Wayland makes it easier than X11, given that all objects are client side and do not asynchronously disappear when the display connection is closed. Sadly, it's still not entirely trivial to achieve; there are more pressing things to do than addressing niche use cases; and this still does not address the issue of Emacs closing display connections at random and expecting things to survive.

Making Emacs popular again

Posted May 7, 2020 12:49 UTC (Thu) by pabs (subscriber, #43278) [Link]

There is an implementation of a crash resilient Wayland compositor available since 2017, in Arcan:

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-c...

Making Emacs popular again

Posted May 7, 2020 13:20 UTC (Thu) by Baughn (subscriber, #124425) [Link] (5 responses)

Compositor crashes are not niche. They happen to me about twice per day, necessitating heavy scripting to get my workspace back in order after each one.

Making Emacs popular again

Posted May 7, 2020 14:30 UTC (Thu) by ebassi (subscriber, #54855) [Link] (4 responses)

Compositor crashes are not niche

Compositor crashes are bugs, not a feature. Bugs ought to be fixed, and compositors should not crash, considering that they are privileged components.

Additionally, terminating the connection should not crash a toolkit, but you should not expect that your application wait for a display reconnection and restart as if nothing happened either. The only safe thing to do is to save local state and terminate.

Making Emacs popular again

Posted May 8, 2020 2:15 UTC (Fri) by pabs (subscriber, #43278) [Link] (3 responses)

My experience is that this class of bug (compositor crashes) has always been present and this isn't ever going to change. So users are always going to experience data loss, having to restart their session and other annoyances that come from this. In the face of that, the right thing to do is implement crash resiliency in both the compositors and the applications, defence in depth and all that. The people concerned about security bugs learned the defence in depth lesson the hard way and it is about time people learned similar things about crash bugs and other bugs too.

Making Emacs popular again

Posted May 8, 2020 22:48 UTC (Fri) by roc (subscriber, #30627) [Link] (2 responses)

You could say exactly the same thing about kernel crashes and power outages.

Therefore your software should not lose data during those events either, and if that's true then a compositor crash likewise doesn't matter.

Making Emacs popular again

Posted May 10, 2020 8:14 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (1 responses)

While probably no software is 100% crash free, some software crashes way more often than other software, and that is a very important consideration to make.

Making Emacs popular again

Posted May 13, 2020 8:53 UTC (Wed) by roc (subscriber, #30627) [Link]

I suppose that's true, but for me the GNOME compositor never crashes and I do occasionally have to reboot for kernel hangs, so I want the applications I use to tolerate the latter.

Making Emacs popular again

Posted May 7, 2020 8:43 UTC (Thu) by vejeta (subscriber, #138096) [Link]

Maybe it is worth sharing in the emacs-devel mailing-list.

I searched the list, and found a mention here:
https://lwn.net/ml/emacs-devel/82460db0-1ecf-cf11-7dbf-d7...

It seems there is a warning that mentions it when compiling emacs, however I don't see a reference to it where this discussion took place.

Making Emacs popular again

Posted May 7, 2020 12:52 UTC (Thu) by ebassi (subscriber, #54855) [Link]

Can anyone clarify if this is accurate?

As the person who wrote the comment you're linking: yes, this is still accurate to the best of my knowledge.

Emacs is specifically calling abort(), and nobody from the Emacs camp has come up with a patch, or at least a description of the required Emacs behaviour that is supposedly not supported by GTK.