Hook for `_exit'

Hook for `_exit'

[Po Lu]

I'd like to ask for a hook run before _exit kills the current thread.
The reason for requesting such a hook is that badly behaved libraries
such as GTK call _exit when the display connection is lost, without
leaving programs a chance to perform cleanup, such as saving files that
the user was working on.

AFAIR, the GTK developers have already mentioned that they are unwilling
to add such a hook on their end (especially to GTK 3, which is no longer
receiving new features), and the chance of updated GTK versions getting
to users is exceedingly slim.

A real life example of this problem would be:

  https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00433.html

Where a user experienced a display disconnect, and as a result lost all
of his work with no clear indication of what happened.

Thanks in advance.

Re: Hook for `_exit'

[Florian Weimer]

* Po Lu via Libc-alpha:

> I'd like to ask for a hook run before _exit kills the current thread.
> The reason for requesting such a hook is that badly behaved libraries
> such as GTK call _exit when the display connection is lost, without
> leaving programs a chance to perform cleanup, such as saving files that
> the user was working on.
>
> AFAIR, the GTK developers have already mentioned that they are unwilling
> to add such a hook on their end (especially to GTK 3, which is no longer
> receiving new features), and the chance of updated GTK versions getting
> to users is exceedingly slim.
>
> A real life example of this problem would be:
>
>   https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00433.html
>
> Where a user experienced a display disconnect, and as a result lost all
> of his work with no clear indication of what happened.

I think even if we add the hook in glibc, GTK will find a way to
terminate the process immediately by other means.  We already have exit,
yet GTK deliberately chose not to use it.  So it doesn't look like
something that can be solved with an in-process hook.

If you need to use a library with such an approach to error handling,
but you want to recover from errors, you need to use fork and confine
its use to a subprocess, and employ some IPC mechanism to maintain
relevant state in a more persistent process (or keep a redo log in the
file system).

Thanks,
Florian

Re: Hook for `_exit'

[Po Lu]

Florian Weimer <fweimer@redhat.com> writes:

> I think even if we add the hook in glibc, GTK will find a way to
> terminate the process immediately by other means.

GTK 3 is already in maintenance mode, so I doubt their developers will
deliberately break programs relying on such a hook.  In any case, it
will let us ship a fix for this common problem to our users now, and
negotiate with the GTK developers later should they break it.

> We already have exit, yet GTK deliberately chose not to use it.  So it
> doesn't look like something that can be solved with an in-process
> hook.

[...]

> If you need to use a library with such an approach to error handling,
> but you want to recover from errors, you need to use fork and confine
> its use to a subprocess, and employ some IPC mechanism to maintain
> relevant state in a more persistent process (or keep a redo log in the
> file system).

I guess that would be possible in theory, but it will be difficult to
work with in Emacs.  With that amount of effort, one might as well throw
away GTK altogether and write a Wayland client from scratch.

Thanks.

Re: Hook for `_exit'

[Florian Weimer]

* Po Lu:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> I think even if we add the hook in glibc, GTK will find a way to
>> terminate the process immediately by other means.
>
> GTK 3 is already in maintenance mode, so I doubt their developers will
> deliberately break programs relying on such a hook.  In any case, it
> will let us ship a fix for this common problem to our users now, and
> negotiate with the GTK developers later should they break it.

It sounds like a bad idea to adopt a library that is already in
maintenance mode.

Why do you expect that its successor will handle this differently?  Does
the successor use exit?

Thanks,
Florian

Re: Hook for `_exit'

[Po Lu]

Florian Weimer <fweimer@redhat.com> writes:

> It sounds like a bad idea to adopt a library that is already in
> maintenance mode.

So far it's proven to be the only practical way of gaining native
Wayland support, and will at least be supported for the foreseeable
future (just without major changes.)

> Why do you expect that its successor will handle this differently?
> Does the successor use exit?

The successor will hopefully be a different toolkit, made by developers
who have sane approaches to handling window-system errors.  But it will
take several years for the other toolkits to catch up with GTK in terms
of Wayland support.

Thanks.

Re: Hook for `_exit'

[Florian Weimer]

* Po Lu:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> It sounds like a bad idea to adopt a library that is already in
>> maintenance mode.
>
> So far it's proven to be the only practical way of gaining native
> Wayland support, and will at least be supported for the foreseeable
> future (just without major changes.)

What about GTK 4?  It looks like GTK 4 uses the same code.

You should ask them to switch to exit in GTK 4, and maybe that change
can be backported, maintenance mode or not.

Given that, it seems very premature to seek a glibc-level solution.

Thanks,
Florian

Re: Hook for `_exit'

[Po Lu]

Florian Weimer <fweimer@redhat.com> writes:

> What about GTK 4?  It looks like GTK 4 uses the same code.
>
> You should ask them to switch to exit in GTK 4, and maybe that change
> can be backported, maintenance mode or not.

We found out in the course of development that GTK 4 is an abysmal
sucessor to GTK 3: it has many bugs in its drag-and-drop and clipboard
code (which was rewritten from scratch for no apparent reason), and
doesn't support subpixel anti-aliasing.  So it's not really practical
for most programs, especially text editors.

Re: Hook for `_exit'

[Florian Weimer]

* Po Lu:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> What about GTK 4?  It looks like GTK 4 uses the same code.
>>
>> You should ask them to switch to exit in GTK 4, and maybe that change
>> can be backported, maintenance mode or not.
>
> We found out in the course of development that GTK 4 is an abysmal
> sucessor to GTK 3: it has many bugs in its drag-and-drop and clipboard
> code (which was rewritten from scratch for no apparent reason), and
> doesn't support subpixel anti-aliasing.  So it's not really practical
> for most programs, especially text editors.

Still it seems the most promising way to fix this in GTK 3, too.

Thanks,
Florian

Re: Hook for `_exit'

[Cyril Hrubis]

Hi!

FYI: https://gitlab.gnome.org/GNOME/gtk/-/issues/4514

-- 
Cyril Hrubis
chrubis@suse.cz

Re: Hook for `_exit'

[Po Lu]

Florian Weimer <fweimer@redhat.com> writes:

>> We found out in the course of development that GTK 4 is an abysmal
>> sucessor to GTK 3: it has many bugs in its drag-and-drop and clipboard
>> code (which was rewritten from scratch for no apparent reason), and
>> doesn't support subpixel anti-aliasing.  So it's not really practical
>> for most programs, especially text editors.
>
> Still it seems the most promising way to fix this in GTK 3, too.

In that case it's been asked several times, usually alongside reports
about the same problem on the GDK X11 backend.  AFAIR the GTK developers
are unwilling to provide proper hooks (or even to use exit) instead.

Re: Hook for `_exit'

[Paul Eggert]

On 8/5/22 03:52, Po Lu via Libc-alpha wrote:
> the GTK developers
> are unwilling to provide proper hooks (or even to use exit) instead.

Matthias suggested in <https://gitlab.gnome.org/GNOME/gtk/-/issues/4514> 
that Emacs could use a g_message hook and parse the message to determine 
that GTK is about to _exit. Although a horrible hack, I've seen worse 
hacks in Emacs.

Re: Hook for `_exit'

[Szabolcs Nagy]

The 08/05/2022 10:43, Paul Eggert wrote:
> On 8/5/22 03:52, Po Lu via Libc-alpha wrote:
> > the GTK developers
> > are unwilling to provide proper hooks (or even to use exit) instead.
> 
> Matthias suggested in <https://gitlab.gnome.org/GNOME/gtk/-/issues/4514>
> that Emacs could use a g_message hook and parse the message to determine
> that GTK is about to _exit. Although a horrible hack, I've seen worse hacks
> in Emacs.

btw can't emacs interpose _exit?

(and use something else when it really wants to exit)

Re: Hook for `_exit'

[Paul Eggert]

On 8/5/22 12:20, Szabolcs Nagy wrote:
> btw can't emacs interpose _exit?

Not portably, no.

Re: Hook for `_exit'

[Adhemerval Zanella]

> On 5 Aug 2022, at 17:12, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 8/5/22 12:20, Szabolcs Nagy wrote:
>> btw can't emacs interpose _exit?
> 
> Not portably, no.

But a possible hook will be glibc specific anyway, so I am not sure why interposing _exit on glibc is not an option for emacs.

Re: Hook for `_exit'

[Po Lu]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 8/5/22 03:52, Po Lu via Libc-alpha wrote:
>> the GTK developers
>> are unwilling to provide proper hooks (or even to use exit) instead.
>
> Matthias suggested in
> <https://gitlab.gnome.org/GNOME/gtk/-/issues/4514> that Emacs could
> use a g_message hook and parse the message to determine that GTK is
> about to _exit. Although a horrible hack, I've seen worse hacks in
> Emacs.

That sounds pretty bad to me, but I think it's workable.
You would have to recognize (at least) the following strings:

  "Lost connection to Wayland compositor."
  "Error %d (%s) dispatching to Wayland display."
  "Error reading events from display: %s"
  "Error flushing display: %s"

But Emacs also supports loading dynamic modules.  What if a module also
calls g_message with a similar string?

Re: Hook for `_exit'

[Paul Eggert]

On 8/5/22 18:37, Po Lu wrote:
> Emacs also supports loading dynamic modules.  What if a module also
> calls g_message with a similar string?

Presumably such a module would follow the same convention, that is, if 
it output any of those messages it would soon _exit. If it doesn't 
follow the convention it would be incompatible with Emacs. Admittedly 
this is a hack.

Re: Hook for `_exit'

[Rich Felker]

On Fri, Aug 05, 2022 at 10:22:11AM +0200, Florian Weimer via Libc-alpha wrote:
> * Po Lu via Libc-alpha:
> 
> > I'd like to ask for a hook run before _exit kills the current thread.
> > The reason for requesting such a hook is that badly behaved libraries
> > such as GTK call _exit when the display connection is lost, without
> > leaving programs a chance to perform cleanup, such as saving files that
> > the user was working on.
> >
> > AFAIR, the GTK developers have already mentioned that they are unwilling
> > to add such a hook on their end (especially to GTK 3, which is no longer
> > receiving new features), and the chance of updated GTK versions getting
> > to users is exceedingly slim.
> >
> > A real life example of this problem would be:
> >
> >   https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00433.html
> >
> > Where a user experienced a display disconnect, and as a result lost all
> > of his work with no clear indication of what happened.
> 
> I think even if we add the hook in glibc, GTK will find a way to
> terminate the process immediately by other means.  We already have exit,
> yet GTK deliberately chose not to use it.  So it doesn't look like
> something that can be solved with an in-process hook.

Exactly. This is just inviting an arms race. Next GTK does
syscall(__NR_exit_group, 1) and then glibc has to make syscall() check
for __NR_exit_group and call the application callback. Then GTK
inlines asm, and glibc needs to install a seccomp handler to block it.
Next...

And that's not even to mention the flip side problem this invites: bad
library code installing hooks for _exit that interfere with the
application's usage of it and make it unsafe, by doing things from the
callback that aren't safe in the context _exit is called from -- _exit
is required to be async-signal safe and can be called from all sorts
of nasty contexts, even vfork child(!!), where it's not safe for
random callback code to run.

> If you need to use a library with such an approach to error handling,
> but you want to recover from errors, you need to use fork and confine
> its use to a subprocess, and employ some IPC mechanism to maintain
> relevant state in a more persistent process (or keep a redo log in the
> file system).

Exactly. If you're going to run badly-behaved library code, you either
need to patch the bad behavior out of the library, or run the library
in an isolated execution context where it can't do any harm. The
latter is really the right approach here. Work out a protocol for
communication between a UI child process and the actual core program
and sandbox the former.