Question about pgtk -- is it meant to fix the disconnect crash bug?

Question about pgtk -- is it meant to fix the disconnect crash bug?

[Sean Whitton]

Hello Yuuki,

Thank you for your work on pgtk; I am trying it out on Wayland for the
first time today.  I noticed that an Emacs daemon started from a tty
crashes when the Wayland compositor exits.  I had thought that one of
the benefits of the pgtk branch was that it would not have this bug,
which plagues the old Emacs GTK builds.  Am I just making that up?

Thanks.

-- 
Sean Whitton

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Robert Pluim]

>>>>> On Wed, 03 Mar 2021 15:51:16 -0700, Sean Whitton <spwhitton@spwhitton.name> said:

    Sean> Hello Yuuki,
    Sean> Thank you for your work on pgtk; I am trying it out on Wayland for the
    Sean> first time today.  I noticed that an Emacs daemon started from a tty
    Sean> crashes when the Wayland compositor exits.  I had thought that one of
    Sean> the benefits of the pgtk branch was that it would not have this bug,
    Sean> which plagues the old Emacs GTK builds.  Am I just making that up?

Unfortunately that issue still exists. Similarly, pgtk emacs crashes
when displaying over a forwarded Wayland connection when the
underlying ssh connection dies.

Someone™ needs to fix this on the GTK side. Previous attempts to get
it fixed have not been met with a great deal of enthusiasm by the GTK
folks (Iʼm expressing myself politely, unlike them).

Robert
-- 

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Yuuki Harano]

Hi,

On Wed, 03 Mar 2021 15:51:16 -0700,
	Sean Whitton <spwhitton@spwhitton.name> wrote:
> I noticed that an Emacs daemon started from a tty
> crashes when the Wayland compositor exits.  I had thought that one of
> the benefits of the pgtk branch was that it would not have this bug,
> which plagues the old Emacs GTK builds.  Am I just making that up?

Gtk calls `_exit(1)` when connection is closed.
I think I can do nothing.

-- 
Yuuki Harano

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[chad]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Wed, Mar 3, 2021 at 2:51 PM Sean Whitton <spwhitton@spwhitton.name>
wrote:

> I had thought that one of
> the benefits of the pgtk branch was that it would not have this bug,
> which plagues the old Emacs GTK builds.  Am I just making that up?
>

Adding a bit of historical perspective: it might be more accurate to say
"the GTK people are unwilling to address the issue when it's caused by what
some people call 'unclean gtk use' inside emacs", with the concomitant hope
that they will more more receptive to a pure-gtk issue. AFAIK, the only
alternative to GTK fixing the problem is something semantically very close
to monkey-patching.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1059 bytes --]

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Daniele Nicolodi]

On 04/03/2021 23:10, chad wrote:
> 
> On Wed, Mar 3, 2021 at 2:51 PM Sean Whitton <spwhitton@spwhitton.name
> <mailto:spwhitton@spwhitton.name>> wrote:
> 
>     I had thought that one of
>     the benefits of the pgtk branch was that it would not have this bug,
>     which plagues the old Emacs GTK builds.  Am I just making that up?
> 
> 
> Adding a bit of historical perspective: it might be more accurate to say
> "the GTK people are unwilling to address the issue when it's caused by
> what some people call 'unclean gtk use' inside emacs", with the
> concomitant hope that they will more more receptive to a pure-gtk issue.
> AFAIK, the only alternative to GTK fixing the problem is something
> semantically very close to monkey-patching.

The last time I looked at this the GTK maintainers are interested in
investigating the bug and fixing it in GTK as long as it does not
involve debugging Emacs but a more manageable reproducer of the issue.
AFAIK, no one tried to provide one.

Also, the last time I looked, Emacs aborts() when it detects the
condition that causes the bug, thus fixing the bug in GTK does not
automatically fix Emacs.

Cheers,
Dan

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[chad]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On Thu, Mar 4, 2021 at 2:58 PM Daniele Nicolodi <daniele@grinta.net> wrote:

> The last time I looked at this the GTK maintainers are interested in
> investigating the bug and fixing it in GTK as long as it does not
> involve debugging Emacs but a more manageable reproducer of the issue.
> AFAIK, no one tried to provide one.
>

That actually does not match my understanding; if I remember correctly, the
GTK people felt that emacs was doing something that they did not want to
support, and since no "well behaved" GTK applications had reported the
problem, they were thus were unwilling to continue. I might be
misremembering.

Also, the last time I looked, Emacs aborts() when it detects the
> condition that causes the bug, thus fixing the bug in GTK does not
> automatically fix Emacs.
>

Emacs added that code as a response to the GTK bug, because calling abort()
itself is minorly cleaner than allowing the crash from _exit() in the
library.

At heart, emacs is trying to use a niche feature that was spec'd but never
fully implemented in gtk/gdk. Nobody else wants to use that feature,
because there just aren't that many apps that want to hop around between
open and closed displays (like emacs --daemon does) AND that also have a
lot of long-lived state (most would be fine with simply closing and
restarting). Web browsers are the nearest candidate that comes to mind, and
they have already invested large-to-massive effort in the alternative "run
distinct copies everywhere, including your phone, and layer on a sync
service for the few places where you might care".

This creates an environment where the GTK maintainers weigh a bunch of
groddy low-level work to support a feature almost no one wants on one side
against a client base that has the highly-functional "just use Lucid"
alternative on the other. This world doesn't produce a lot of motivation to
solve the problem, and the solution will likely (if I understand the
decade-plus-old bug-thread) require fairly low-level changes to gtk/gdk, so
the solver needs to be very familiar with gdk internals, so the friction is
quite high. In the meantime, X11 is due to be obsoleted every few years for
the last decade...

~Chad

[-- Attachment #2: Type: text/html, Size: 2832 bytes --]

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Stefan Monnier]

>> The last time I looked at this the GTK maintainers are interested in
>> investigating the bug and fixing it in GTK as long as it does not
>> involve debugging Emacs but a more manageable reproducer of the issue.
>> AFAIK, no one tried to provide one.
>
> That actually does not match my understanding; if I remember correctly, the
> GTK people felt that emacs was doing something that they did not want to
> support, and since no "well behaved" GTK applications had reported the
> problem, they were thus were unwilling to continue. I might be
> misremembering.

AFAICT these two views are actually one and the same, just using
different words.


        Stefan

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Thu, 4 Mar 2021 14:10:39 -0800
> Cc: Yuuki Harano <masm+emacs@masm11.me>,
>  EMACS development team <emacs-devel@gnu.org>
> 
>  I had thought that one of
>  the benefits of the pgtk branch was that it would not have this bug,
>  which plagues the old Emacs GTK builds.  Am I just making that up?
> 
> Adding a bit of historical perspective: it might be more accurate to say "the GTK people are unwilling to
> address the issue when it's caused by what some people call 'unclean gtk use' inside emacs", with the
> concomitant hope that they will more more receptive to a pure-gtk issue.

Isn't the pgtk branch supposed to produce a "clean GTK use" inside
Emacs?  I thought that was its purpose.

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Thu, 4 Mar 2021 23:57:02 +0100
> 
> Also, the last time I looked, Emacs aborts() when it detects the
> condition that causes the bug, thus fixing the bug in GTK does not
> automatically fix Emacs.

AFAIU, the problem in this case is that GTK itself calls _exit, not
that Emacs calls abort.

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[chad]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

On Thu, Mar 4, 2021 at 10:38 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: chad <yandros@gmail.com>
> > Date: Thu, 4 Mar 2021 14:10:39 -0800
> > Cc: Yuuki Harano <masm+emacs@masm11.me>,
> >  EMACS development team <emacs-devel@gnu.org>
> >
> >  I had thought that one of
> >  the benefits of the pgtk branch was that it would not have this bug,
> >  which plagues the old Emacs GTK builds.  Am I just making that up?
> >
> > Adding a bit of historical perspective: it might be more accurate to say
> "the GTK people are unwilling to
> > address the issue when it's caused by what some people call 'unclean gtk
> use' inside emacs", with the
> > concomitant hope that they will more more receptive to a pure-gtk issue.
>
> Isn't the pgtk branch supposed to produce a "clean GTK use" inside
> Emacs?  I thought that was its purpose.
>

As I understand it, yes. This has the potential upsides of better
integration and maybe a better fit for a theoretically post-X11 world.
Another hopeful upside it "fewer years of Martin's life lost to
frustration, etc". It might also help people find and solve the issue with
gtk/gdk opening/closing/reopening display connections, but that doesn't
seem certain to me: they asked for a simpler case than "all of emacs", and
I'm not sure that "a different emacs" will be sufficient. I base this
skepticism on the understanding that there is no doubt that the problem
exists or (roughly) where, but rather that it is worth the required effort
from the limited pool of people who are in position to do it.

I can't help but notice that Wayland offers a potential "solution" by
simply not supporting the underlying functionality that triggers the
problem. In terms of "kicking the can down the road", the basic Wayland
approach is "We're making something that you might use as a can. We do not
promise that 'kicking' will apply to it, and explicitly disclaim any
concept of 'road'." They're doing this to keep the problem more tractable;
the emacs/gtk bug is one example of the sort of thing that they're
explicitly labelling "Somebody Else's Problem".

Again, I hope this helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2924 bytes --]

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[Robert Pluim]

>>>>> On Fri, 5 Mar 2021 12:35:11 -0800, chad <yandros@gmail.com> said:

    chad> I can't help but notice that Wayland offers a potential "solution" by
    chad> simply not supporting the underlying functionality that triggers the
    chad> problem. In terms of "kicking the can down the road", the basic Wayland
    chad> approach is "We're making something that you might use as a can. We do not
    chad> promise that 'kicking' will apply to it, and explicitly disclaim any
    chad> concept of 'road'." They're doing this to keep the problem more tractable;
    chad> the emacs/gtk bug is one example of the sort of thing that they're
    chad> explicitly labelling "Somebody Else's Problem".

For Wayland you can use waypipe to forward to a different display.

Robert
-- 

Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[David De La Harpe Golden]

haven't really looked into it, just have a watch on the gtk-side issue 
ticket(s)*, but just mentioning I did just notice a Michel Dänzer 
commenting the below just today on the gtk-side bug:

https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481

 > FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing
 > X11 client window decorations) is able to survive Xwayland dying
 > abruptly, using the new XSetIOErrorExitHandler API (which removes the
 > need for longjmp hacks) available as of libX11 1.7.0.
 >
 > I don't know if the same approach can work for Emacs as well though.




* the whole "gtk emacs sudden death" thing having been a minor annoyance 
for years of course