GNU bug report logs - #53013
29.0.50; xwidget-webkit: SIGCHLD not being caught after xwidget-webkit buffer killed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53013 in the body.
You can then email your comments to 53013 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Akira Kyle <akira <at> akirakyle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; xwidget-webkit: SIGCHLD not being caught after
 xwidget-webkit buffer killed
Date: Tue, 04 Jan 2022 14:10:05 -0700

In GNU Emacs 29.0.50 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
Repository revision: ab5ee3e29e916d4009b301841e9780aad564a6a0
Repository branch: master
System Description: NixOS 22.05 (Quokka)

Configured using:
 'configure
 --prefix=/nix/store/0fiqa453abl4c1c28g0baqs9s274s7ff-emacs-pgtkgcc-20220103.0
 --disable-build-details --with-modules --with-x-toolkit=gtk3
 --with-cairo --with-xwidgets --with-native-compilation --with-pgtk'

Also tested on debian under GNOME (wayland) with the same configuration.

Steps to reproduce in emacs -Q:
- M-x xwidget-webkit-browse-url RET http://xkcd.com RET
- C-x k RET
- M-: (start-process "my-process" "foo" "echo" "hi")

No "Process my-process finished" line appears in buffer "foo" indicating
that emacs didn't catch SIGCHLD.

I suspect that a call to catch_child_signal might also be needed in
kill_xwidget so emacs reinstalls its signal handler.

Message #8 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Akira Kyle <akira <at> akirakyle.com>
Cc: 53013 <at> debbugs.gnu.org
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Wed, 05 Jan 2022 10:40:40 +0800

Akira Kyle <akira <at> akirakyle.com> writes:

> I suspect that a call to catch_child_signal might also be needed in
> kill_xwidget so emacs reinstalls its signal handler.

Should be fixed now on master.

Making kill_xwidget call catch_child_signal wasn't enough, since GLib
was resetting SIGCHLD inside a timer set by WebKitGTK and about a dozen
other places as well, hence the very ugly (and unreliable) hack on
master.

It's a temporary solution that just motivated me to look at making Emacs
use GLib for handling subprocesses.

Message #11 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Akira Kyle <akira <at> akirakyle.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53013 <at> debbugs.gnu.org
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Tue, 4 Jan 2022 22:04:22 -0700

On Tue, Jan 4, 2022 at 7:40 PM Po Lu <luangruo <at> yahoo.com> wrote:
>
> > I suspect that a call to catch_child_signal might also be needed in
> > kill_xwidget so emacs reinstalls its signal handler.
>
> Should be fixed now on master.
>

It looks like SIGCHLD is now being caught by emacs for me. Thanks!

> Making kill_xwidget call catch_child_signal wasn't enough, since GLib
> was resetting SIGCHLD inside a timer set by WebKitGTK and about a dozen
> other places as well, hence the very ugly (and unreliable) hack on
> master.
>
> It's a temporary solution that just motivated me to look at making Emacs
> use GLib for handling subprocesses.

Indeed GLib does appear to want to always own the signal handling and
I imagine the current hacks of trying to constantly reinstall the
handler are also potentially brittle solutions to the problem.

Message #14 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Akira Kyle <akira <at> akirakyle.com>
Cc: luangruo <at> yahoo.com, 53013 <at> debbugs.gnu.org
Subject: Re: bug#53013: 29.0.50;
 xwidget-webkit: SIGCHLD not being caught after xwidget-webkit buffer
 killed
Date: Thu, 06 Jan 2022 23:21:08 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Emacs does a lot of special things in handling subprocesses,
and that is a very important feature.

On general principles, I think that means we should perfect our own code
rather than try to use code maintained by another project for this.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #17 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 53013 <at> debbugs.gnu.org, Akira Kyle <akira <at> akirakyle.com>
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Fri, 07 Jan 2022 12:40:30 +0800

Richard Stallman <rms <at> gnu.org> writes:

> Emacs does a lot of special things in handling subprocesses, and that
> is a very important feature.
>
> On general principles, I think that means we should perfect our own
> code rather than try to use code maintained by another project for
> this.

I'm not talking about replacing Emacs's own code with GLib's system
entirely, but just relying on GLib to tell us when a process exits,
instead of installing our own SIGCHLD handler.

Thanks.

Message #20 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53013 <at> debbugs.gnu.org, akira <at> akirakyle.com
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Fri, 07 Jan 2022 22:58:54 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm not talking about replacing Emacs's own code with GLib's system
  > entirely, but just relying on GLib to tell us when a process exits,
  > instead of installing our own SIGCHLD handler.

I don't know enough to have an opinion in detail, but on general
principles I suggest that we fix our own code.  Depending on an
external package for little bits of Emacs is asking for trouble.  Our
code can have bugs, and the Glib code can have bugs, but if our
code has bugs, there is no obstacle to our using a fixed version.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #23 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 53013 <at> debbugs.gnu.org, akira <at> akirakyle.com
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Sat, 08 Jan 2022 12:37:03 +0800

Richard Stallman <rms <at> gnu.org> writes:

> I don't know enough to have an opinion in detail, but on general
> principles I suggest that we fix our own code.  Depending on an
> external package for little bits of Emacs is asking for trouble.  Our
> code can have bugs, and the Glib code can have bugs, but if our
> code has bugs, there is no obstacle to our using a fixed version.

I'm only proposing to use GLib's code in Emacs builds that have GLib.
(Those which use GTK+, for example, must have GLib.)

The reason is that GLib resets the Emacs SIGCHLD handler at random
spots, which is very difficult to work around.

Thanks.

Message #26 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53013 <at> debbugs.gnu.org, akira <at> akirakyle.com
Subject: Re: bug#53013: 29.0.50;
 xwidget-webkit: SIGCHLD not being caught after xwidget-webkit buffer
 killed
Date: Sat, 08 Jan 2022 22:54:52 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm only proposing to use GLib's code in Emacs builds that have GLib.
  > (Those which use GTK+, for example, must have GLib.)

Maybe you're right.  I am no expert on this so I will leave it to others.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #29 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Akira Kyle <akira <at> akirakyle.com>
Cc: Po Lu <luangruo <at> yahoo.com>, 53013 <at> debbugs.gnu.org
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Fri, 14 Jan 2022 09:19:43 +0100

Akira Kyle <akira <at> akirakyle.com> writes:

> It looks like SIGCHLD is now being caught by emacs for me. Thanks!

I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #34 received at 53013 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53013 <at> debbugs.gnu.org, Akira Kyle <akira <at> akirakyle.com>
Subject: Re: bug#53013: 29.0.50; xwidget-webkit: SIGCHLD not being caught
 after xwidget-webkit buffer killed
Date: Fri, 14 Jan 2022 09:20:19 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> It's a temporary solution that just motivated me to look at making Emacs
> use GLib for handling subprocesses.

I think that's certainly worth a try -- we've had a lot of these issues
over the years.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.