Interferences between xwidgets and async processes?

Interferences between xwidgets and async processes?

[JIANG Shaojian]

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

Hi,

I found a problem when using emacs 28 with xwidgets support. I am not sure
whether it is a bug. Any hint is appreciated.

Here is how to reproduce it:

emacs -Q

M-: (start-process "test1" "t1" "echo" "t1")
This creates a buffer "t1" with content
--------------------------------
t1

Process test1 finished
---------------------------------
which is normal, and M-x list-processes shows nothing since process "test1"
is already finished.

Next, I start an xwidget
M-x xwidget-webkit-browse-url with some url
and then start async processes similarly
M-: (start-process "test2" "t2" "echo" "t2")
The buffer "t2" has content
--------------------------------
t2

---------------------------------
M-x list-processes shows the running process "test2", so apparently the
process "test2" is not finished as it should be.

This behavior does not change whether you close the seemingly unrelated
xwidget buffer or not.
In fact, I do not find any way to cure this except restarting emacs.

Below is the testing environment:
emacs version: 28.0.50 (built on 2020-9-22)
build option: --with-x --with-mailutils --with-modules --with-xwidgets
--with-jansson
OS: linux

PS: emacs 28 under MacOS with patched xwidgets support does not have this
problem.

Thanks.

Best,
SJ

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

Re: Interferences between xwidgets and async processes?

[Lars Ingebrigtsen]

JIANG Shaojian <sdycjsj@gmail.com> writes:

> M-x list-processes shows the running process "test2", so apparently
> the process "test2" is not finished as it should be.

I can confirm this bug (on Debian bullseye).

list-processes says:

test1           3961402 run     t1                        /dev/pts/7   Main         echo t1

(process-status p)
=> run

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

Re: Interferences between xwidgets and async processes?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Oct 2020 09:24:24 +0100
> Cc: emacs-devel@gnu.org
> 
> JIANG Shaojian <sdycjsj@gmail.com> writes:
> 
> > M-x list-processes shows the running process "test2", so apparently
> > the process "test2" is not finished as it should be.
> 
> I can confirm this bug (on Debian bullseye).
> 
> list-processes says:
> 
> test1           3961402 run     t1                        /dev/pts/7   Main         echo t1
> 
> (process-status p)
> => run

What happens in reality, though? is the process really still running,
or is it dead and our sentinel was not called?

Re: Interferences between xwidgets and async processes?

[JIANG Shaojian]

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

Using "top", I can see that the status of the process is "Z".

Eli Zaretskii <eliz@gnu.org> 于2020年10月28日周三 下午11:12写道：

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Wed, 28 Oct 2020 09:24:24 +0100
> > Cc: emacs-devel@gnu.org
> >
> > JIANG Shaojian <sdycjsj@gmail.com> writes:
> >
> > > M-x list-processes shows the running process "test2", so apparently
> > > the process "test2" is not finished as it should be.
> >
> > I can confirm this bug (on Debian bullseye).
> >
> > list-processes says:
> >
> > test1           3961402 run     t1                        /dev/pts/7
>  Main         echo t1
> >
> > (process-status p)
> > => run
>
> What happens in reality, though? is the process really still running,
> or is it dead and our sentinel was not called?
>

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

Re: Interferences between xwidgets and async processes?

[Eli Zaretskii]

> From: JIANG Shaojian <sdycjsj@gmail.com>
> Date: Thu, 29 Oct 2020 10:43:30 +0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> Using "top", I can see that the status of the process is "Z".

Which AFAIU means that the process indeed exited, but our sentinel was
not called, and we therefore didn't yet request the process's exit
status.

Is it possible that xwidgets somehow block SIGCHLD, or cause us to
miss it?

Re: [PATCH] Interferences between xwidgets and async processes?

[Akira Kyle]

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


On Thu, Oct 29, 2020 at 08:23 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

>> Using "top", I can see that the status of the process is "Z".
>
> Which AFAIU means that the process indeed exited, but our 
> sentinel was
> not called, and we therefore didn't yet request the process's 
> exit
> status.
>
> Is it possible that xwidgets somehow block SIGCHLD, or cause us 
> to
> miss it?


Its seems like this is what is happening. The relevant glib 
function which sets up the SIGCHLD signal handler is 
ref_unix_signal_handler_unlocked. It doesn't respect existing 
signal handlers like Emacs does in catch_child_signal and call 
them after it's own handling hence the need for the hack in 
init_process_emacs (process.c) that forces glib to not catch 
SIGCHLD. Setting a breakpoint on ref_unix_signal_handler_unlocked 
the backtrace:

#0  0x0000fffff704b66c in ref_unix_signal_handler_unlocked () from 
 /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libglib-2.0.so.0
#1  0x0000fffff704b8f0 in g_child_watch_source_new () from 
 /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libglib-2.0.so.0
#2  0x0000fffff725a6b4 in initable_init () from 
 /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libgio-2.0.so.0
#3  0x0000fffff72596b0 in g_subprocess_launcher_spawnv () from 
 /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libgio-2.0.so.0
#4  0x0000ffffc906707c in WebKit::ProcessLauncher::launchProcess() 
 () from 
 /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#5  0x0000ffffc8eea1d0 in WebKit::AuxiliaryProcessProxy::connect() 
 () from 
 /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#6  0x0000ffffc8f45660 in 
 WebKit::WebProcessProxy::create(WebKit::WebProcessPool&, 
 WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::IsPrewarmed, 
 WebKit::WebProcessProxy::ShouldLaunchProcess) ()
   from 
   /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#7  0x0000ffffc8f64bb4 in 
 WebKit::WebProcessPool::createNewWebProcess(WebKit::WebsiteDataStore*, 
 WebKit::WebProcessProxy::IsPrewarmed) ()
   from 
   /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#8  0x0000ffffc8f6b740 in 
 WebKit::WebProcessPool::processForRegistrableDomain(WebKit::WebsiteDataStore&, 
 WebKit::WebPageProxy*, WebCore::RegistrableDomain const&) ()
   from 
   /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#9  0x0000ffffc8f6b844 in 
 WebKit::WebPageProxy::launchProcess(WebCore::RegistrableDomain 
 const&, WebKit::WebPageProxy::ProcessLaunchReason) ()
   from 
   /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#10 0x0000ffffc8f6de3c in 
 WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&, 
 WebCore::ShouldOpenExternalURLsPolicy, API::Object*) ()
   from 
   /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#11 0x0000ffffc9006c70 in webkit_web_view_load_uri () from 
 /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
#12 0x0000ffffd684c528 in ?? () from 
 /run/user/1001/webkitgtk-module.soxgSF5U.so
#13 0x000000000056eadc in funcall_module (function=0x3c97cf5, 
 nargs=2, arglist=0xffffffff3110) at emacs-module.c:1186
#14 0x0000000000545180 in funcall_lambda (fun=fun@entry=0x2a90, 
 nargs=nargs@entry=2, arg_vector=0xffffffff20f0, 
 arg_vector@entry=0xffffffff3110) at eval.c:3083
#15 0x0000000000544570 in apply_lambda (fun=0x2a90, 
 fun@entry=0x3c97cf5, args=<optimized out>, count=count@entry=24) 
 at eval.c:3021
#16 0x00000000005447cc in eval_sub (form=<optimized out>) at 
 eval.c:2424
#17 0x0000000000544dbc in Fprogn (body=0x0) at eval.c:471
#18 0x0000000000545048 in funcall_lambda (fun=<optimized out>, 
 nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xffffffff33e0) 
 at lisp.h:1426
#19 0x000000000054274c in Ffuncall (nargs=nargs@entry=3, 
 args=args@entry=0xffffffff33d8) at eval.c:2888
#20 0x000000000053f248 in Ffuncall_interactively (nargs=3, 
 args=0xffffffff33d8) at callint.c:253
#21 0x0000000000542870 in Ffuncall (nargs=nargs@entry=4, 
 args=args@entry=0xffffffff33d0) at lisp.h:2091
#22 0x0000000000542b70 in Fapply (nargs=nargs@entry=3, 
 args=0xffffffff3570, args@entry=0xffffffff3660) at eval.c:2502
#23 0x00000000005405e4 in Fcall_interactively 
 (function=0xffffffff3730, record_flag=0xffffffff3630, 
 keys=0x57d418 <exec_byte_code+736>) at lisp.h:1008
#24 0x0000fffff27262d0 in 
 F636f6d6d616e642d65786563757465_command_execute_0 ()
   from 
   /home/akyle/git/emacs/src/../native-lisp/28.0.50-aarch64-unknown-linux-gnu-08c187d985df753847bb1095eac8e39c/simple-fab5b0cffee734040ac60e9bc557cd20-fad2d213fe4820237be2ea92815644a6.eln
#25 0x0000000000542870 in Ffuncall (nargs=<optimized out>, 
 args=args@entry=0xffffffff36a0) at lisp.h:2091
#26 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0x406, nargs=nargs@entry=1, args=<optimized out>, 
 args@entry=0xffffffff3868)
    at bytecode.c:632
#27 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff3868, nargs=1, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#28 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=1, 
 arg_vector=arg_vector@entry=0xffffffff3868) at eval.c:3077
#29 0x000000000054274c in Ffuncall (nargs=2, 
 args=args@entry=0xffffffff3860) at eval.c:2888
#30 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0x2, nargs=nargs@entry=0, args=<optimized out>, 
 args@entry=0xffffffff3ad0)
    at bytecode.c:632
#31 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff3ad0, nargs=0, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#32 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=0, 
 arg_vector=arg_vector@entry=0xffffffff3ad0) at eval.c:3077
#33 0x000000000054274c in Ffuncall (nargs=1, 
 args=args@entry=0xffffffff3ac8) at eval.c:2888
#34 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0xa0a, nargs=nargs@entry=16, args=<optimized out>, 
 args@entry=0xffffffff3fc8)
    at bytecode.c:632
#35 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff3fc8, nargs=16, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#36 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=16, 
 arg_vector=arg_vector@entry=0xffffffff3fc8) at eval.c:3077
#37 0x000000000054274c in Ffuncall (nargs=nargs@entry=17, 
 args=args@entry=0xffffffff3fc0) at eval.c:2888
#38 0x0000000000542b70 in Fapply (nargs=<optimized out>, 
 args=0xffffffff4150) at eval.c:2502
#39 0x0000000000542870 in Ffuncall (nargs=<optimized out>, 
 args=args@entry=0xffffffff4148) at lisp.h:2091
#40 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0x606, nargs=nargs@entry=17, args=<optimized out>, 
 args@entry=0xffffffff4298)
    at bytecode.c:632
#41 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff4298, nargs=17, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#42 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=17, 
 arg_vector=arg_vector@entry=0xffffffff4298) at eval.c:3077
#43 0x000000000054274c in Ffuncall (nargs=nargs@entry=18, 
 args=args@entry=0xffffffff4290) at eval.c:2888
#44 0x0000000000542b70 in Fapply (nargs=<optimized out>, 
 args=0xffffffff4418) at eval.c:2502
#45 0x0000000000542870 in Ffuncall (nargs=<optimized out>, 
 args=args@entry=0xffffffff4410) at lisp.h:2091
#46 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0x202, nargs=nargs@entry=16, args=<optimized out>, 
 args@entry=0xffffffff4570)
    at bytecode.c:632
#47 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff4570, nargs=16, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#48 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=16, 
 arg_vector=arg_vector@entry=0xffffffff4570) at eval.c:3077
#49 0x000000000054274c in Ffuncall (nargs=17, 
 args=args@entry=0xffffffff4568) at eval.c:2888
#50 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>, 
 vector=<optimized out>, maxdepth=<optimized out>, 
 args_template=0x402, nargs=nargs@entry=0, args=<optimized out>, 
 args@entry=0xffffffff4950)
    at bytecode.c:632
#51 0x0000000000545130 in fetch_and_exec_byte_code 
 (args=0xffffffff4950, nargs=0, syms_left=<optimized out>, 
 fun=<optimized out>) at lisp.h:1838
#52 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=0, 
 arg_vector=arg_vector@entry=0xffffffff4950) at eval.c:3077
#53 0x000000000054274c in Ffuncall (nargs=nargs@entry=1, 
 args=args@entry=0xffffffff4948) at eval.c:2888
#54 0x000000000053f248 in Ffuncall_interactively (nargs=1, 
 args=0xffffffff4948) at callint.c:253
#55 0x0000000000542870 in Ffuncall (nargs=nargs@entry=2, 
 args=args@entry=0xffffffff4940) at lisp.h:2091
#56 0x0000000000542c1c in Fapply (nargs=nargs@entry=3, 
 args=0xffffffff4940, args@entry=0xffffffff4a30) at eval.c:2455
#57 0x00000000005405e4 in Fcall_interactively 
 (function=0xffffffff4a60, record_flag=0xffffffff4a00, 
 keys=0x542950 <call1+56>) at lisp.h:1008
#58 0x0000fffff27262d0 in 
 F636f6d6d616e642d65786563757465_command_execute_0 ()
   from 
   /home/akyle/git/emacs/src/../native-lisp/28.0.50-aarch64-unknown-linux-gnu-08c187d985df753847bb1095eac8e39c/simple-fab5b0cffee734040ac60e9bc557cd20-fad2d213fe4820237be2ea92815644a6.eln
#59 0x0000000000542870 in Ffuncall (nargs=nargs@entry=2, 
 args=args@entry=0xffffffff4a88) at lisp.h:2091
#60 0x0000000000542950 in call1 (fn=fn@entry=0x42c0, 
 arg1=<optimized out>) at eval.c:2732
#61 0x00000000004dc4b8 in command_loop_1 () at lisp.h:1008
#62 0x00000000005419b8 in internal_condition_case 
 (bfun=bfun@entry=0x4dc100 <command_loop_1>, 
 handlers=handlers@entry=0x90, hfun=hfun@entry=0x4d1518 
 <cmd_error>) at eval.c:1365
#63 0x00000000004cded8 in command_loop_2 (ignore=ignore@entry=0x0) 
 at lisp.h:1008
#64 0x000000000054191c in internal_catch (tag=tag@entry=0xe040, 
 func=func@entry=0x4cdea8 <command_loop_2>, arg=arg@entry=0x0) at 
 eval.c:1126
#65 0x00000000004cde74 in command_loop () at lisp.h:1008
#66 0x00000000004d108c in recursive_edit_1 () at keyboard.c:718
#67 0x00000000004d143c in Frecursive_edit () at keyboard.c:790
#68 0x000000000041f0c4 in main (argc=<optimized out>, 
 argv=<optimized out>) at emacs.c:2095

So it seems webkitgtk's use of GSubprocess is what is causing glib 
to take back control of the SIGCHLD sigaction and thus Emacs never 
receives it. Specifically this is the troublesome section (line 
590 in glib/gio 2.64.5 gsubprocess.c)

/* Start attempting to reap the child immediately */
if (success)
{
    GMainContext *worker_context;
    GSource *source;

    worker_context = GLIB_PRIVATE_CALL (g_get_worker_context) ();
    source = g_child_watch_source_new (self->pid);
    g_source_set_callback (source, (GSourceFunc) 
    g_subprocess_exited, g_object_ref (self), g_object_unref);
    g_source_attach (source, worker_context);
    g_source_unref (source);
}

This ends up calling ref_unix_signal_handler_unlocked in gmain.c 
which installs its own signal handler and glib doesn't restore the 
previous signal handler when its done 
unref_unix_signal_handler_unlocked. This issue was brought up on 
the GNOME mailing lists but it doesn't look like anyone responded 
[1].

We can just handle restoring the signal handler ourselves with the 
attached patch.


[1] 
https://mail.gnome.org/archives/gtk-devel-list/2016-October/msg00015.html


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xwidget patch --]
[-- Type: text/x-patch, Size: 1280 bytes --]

From 54c0cfdba0ae036cfca6083154ed52f7e2499174 Mon Sep 17 00:00:00 2001
From: Akira Kyle <akira@akirakyle.com>
Date: Thu, 5 Nov 2020 13:20:42 -0700
Subject: [PATCH] Fix xwidget's webkitgtk widget overriding of Emacs SIGCHLD
 handler

* src/xwidget.c (make-xwidget): Save and restore Emacs SIGCHLD signal
handler since glib doesn't (but should) do this.
---
 src/xwidget.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/src/xwidget.c b/src/xwidget.c
index c505af58f6..69f0e03625 100644
--- a/src/xwidget.c
+++ b/src/xwidget.c
@@ -125,6 +125,16 @@ DEFUN ("make-xwidget",
       if (EQ (xw->type, Qwebkit))
         {
           xw->widget_osr = webkit_web_view_new ();
+
+          /* webkitgtk uses GSubprocess which sets sigaction causing
+             emacs to not catch SIGCHLD with it's usual handle setup
+             in catch_child_signal().
+             This resets the SIGCHLD sigaction */
+          struct sigaction old_action;
+          sigaction (SIGCHLD, NULL, &old_action);
+          webkit_web_view_load_uri(WEBKIT_WEB_VIEW (xw->widget_osr),
+                                   "about:blank");
+          sigaction (SIGCHLD, &old_action, NULL);
         }
 
       gtk_widget_set_size_request (GTK_WIDGET (xw->widget_osr), xw->width,
-- 
2.28.0

Re: [PATCH] Interferences between xwidgets and async processes?

[Robert Pluim]

Akira Kyle <ak@akirakyle.com> writes:

> +
> +          /* webkitgtk uses GSubprocess which sets sigaction causing
> +             emacs to not catch SIGCHLD with it's usual handle setup

Augh. "itʼs" == "it is". Youʼre looking for the possesive "its"

Robert

Re: [PATCH] Interferences between xwidgets and async processes?

[Lars Ingebrigtsen]

Akira Kyle <ak@akirakyle.com> writes:

> * src/xwidget.c (make-xwidget): Save and restore Emacs SIGCHLD signal
> handler since glib doesn't (but should) do this.

Thanks for the analysis and the patch for this problem.  I've now
applied it to Emacs 28, and it fixes the issue here.

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

Re: [PATCH] Interferences between xwidgets and async processes?

[Akira Kyle]

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


On Mon, Nov 09, 2020 at 06:52 AM, Lars Ingebrigtsen 
<larsi@gnus.org> wrote:

>> * src/xwidget.c (make-xwidget): Save and restore Emacs SIGCHLD 
>> signal
>> handler since glib doesn't (but should) do this.
>
> Thanks for the analysis and the patch for this problem.  I've 
> now
> applied it to Emacs 28, and it fixes the issue here.

It seems I jumped the gun on this one. While it does fix the 
reported issue, it leaves WebKit process zombies. The issue is 
deeper than I previously thought and it seems that even 
disregarding the xwidget feature, the current interplay between 
Emacs' and glib's signal handling is fundamentally broken since 
glib commit 2e471acf. The relevant glib issue that resulted in 
that commit is here [1].

Essentially Emacs tries to capture glib's signal handler, 
g_unix_signal_handler, into lib_child_handler in process.c so that 
when Emacs installs its own signal handler, deliver_child_signal, 
overwriting glib's, after deliver_child_signal handles waiting on 
any process Emacs starts, it calls  g_unix_signal_handler so glib 
has the chance to wait on any process it may be handling. The 
comment before defining lib_child_handler in process.c explains 
this intent. However since glib 2e471acf breaks all this since 
glib now may install its signal handler multiple times instead of 
just once and will reset the signal handler to SIG_DFL if it 
doesn't have any watchers on that signal. I'm somewhat surprised 
this hasn't caused other issues so far, but I guess Emacs doesn't 
use glib for any process handling and own its own gtk isn't 
spawning any of its own processes on behalf of Emacs.

The attached patch fixes this but only in a temporary way. Any 
Emacs code which uses gtk or glib to spawn a process will suffer 
the same bugs as the reported xwidget bug unless they are also 
fixed in a similar way to the patch I previously sent, however 
even then my previous patch has potential race conditions as an 
Emacs managed subprocess may throw SIGCHLD between glib installing 
g_unix_signal_handler in ref_unix_signal_handler_unlocked and 
Emacs calling sigaction to restore deliver_child_signal which will 
leave the process zombied so Emacs will need to block SIGCHLD 
during this, something my previous patch failed to consider.

I think that this should ultimately be fixed in glib by making it 
be a better signal handling citizen and do what Emacs does by 
saving any existing signal handler and call it from its own signal 
handler. I suppose I might be able to send them a patch if that 
seems like the best course of action here.

[1] https://gitlab.gnome.org/GNOME/glib/-/issues/733


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Work-around-glib-messing-with-signal-handlers-more-t.patch --]
[-- Type: text/x-patch, Size: 2094 bytes --]

From 3d9406f7a320c241c1105ab8c8051afa682907b7 Mon Sep 17 00:00:00 2001
From: Akira Kyle <akira@akirakyle.com>
Date: Thu, 12 Nov 2020 11:47:14 -0700
Subject: [PATCH] Work around glib messing with signal handlers more than it
 should

* src/process.c (init_process_emacs): force glib's g_unix_signal
handler into lib_child_handler where it should belong.
---
 src/process.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/src/process.c b/src/process.c
index 5c3c82c97f..69d71bf11d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -8221,13 +8221,30 @@ init_process_emacs (int sockfd)
   if (!will_dump_with_unexec_p ())
     {
 #if defined HAVE_GLIB && !defined WINDOWSNT
-      /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
-	 this should always fail, but is enough to initialize glib's
+      /* Tickle glib's child-handling code.  Ask glib to install a
+	 watch source for Emacs itself which will initialize glib's
 	 private SIGCHLD handler, allowing catch_child_signal to copy
-	 it into lib_child_handler.  */
-      g_source_unref (g_child_watch_source_new (getpid ()));
-#endif
+	 it into lib_child_handler.
+
+         Unfortunatly in glib commit 2e471acf, the behavior changed to
+         always install a signal handler when g_child_watch_source_new
+         is called and not just the first time it's called. Glib also
+         now resets signal handlers to SIG_DFL when it no longer has a
+         watcher on that signal. This is a hackey work around to get
+         glib's g_unix_signal_handler into lib_child_handler.
+      */
+      GSource *source = g_child_watch_source_new (getpid ());
+      catch_child_signal ();
+      g_source_unref (source);
+
+      eassert (lib_child_handler != dummy_handler);
+      signal_handler_t lib_child_handler_glib = lib_child_handler;
       catch_child_signal ();
+      eassert (lib_child_handler == dummy_handler);
+      lib_child_handler = lib_child_handler_glib;
+#else
+      catch_child_signal ();
+#endif
     }
 
 #ifdef HAVE_SETRLIMIT
-- 
2.29.0

Re: [PATCH] Interferences between xwidgets and async processes?

[Lars Ingebrigtsen]

Akira Kyle <ak@akirakyle.com> writes:

> However since glib 2e471acf breaks all this since glib now may install
> its signal handler multiple times instead of just once and will reset
> the signal handler to SIG_DFL if it doesn't have any watchers on that
> signal.

Oh, what a mess.

> I'm somewhat surprised this hasn't caused other issues so far,
> but I guess Emacs doesn't use glib for any process handling and own
> its own gtk isn't spawning any of its own processes on behalf of
> Emacs.

Yeah, the xwidget code is the only one I can recall doing this stuff.
Anybody? 

> The attached patch fixes this but only in a temporary way.

Thanks; applied to Emacs 28.  (I counted non-comment lines, and we're
still just below the number of lines before we need an FSF copyright
assignment.  I forget whether I've asked this before -- would you be
willing to sign such paperwork, so that future patches can be applied?)

> I think that this should ultimately be fixed in glib by making it be a
> better signal handling citizen and do what Emacs does by saving any
> existing signal handler and call it from its own signal handler. I
> suppose I might be able to send them a patch if that seems like the
> best course of action here.
>
> [1] https://gitlab.gnome.org/GNOME/glib/-/issues/733

Yes, I think having a fix on the glib side sounds like the only
workeable long-term solution.

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

Re: [PATCH] Interferences between xwidgets and async processes?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  JIANG Shaojian <sdycjsj@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 14 Nov 2020 16:43:39 +0100
> 
> > The attached patch fixes this but only in a temporary way.
> 
> Thanks; applied to Emacs 28.

Just to be sure: the fix that is now installed on master does support
current and old versions of Glib, where the old code seemed to work?
Or does it break with older Glib versions?

Re: [PATCH] Interferences between xwidgets and async processes?

[Akira Kyle]

On Sat, Nov 14, 2020 at 09:22 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

>> > The attached patch fixes this but only in a temporary way.
>> 
>> Thanks; applied to Emacs 28.
>
> Just to be sure: the fix that is now installed on master does 
> support
> current and old versions of Glib, where the old code seemed to 
> work?
> Or does it break with older Glib versions?

I didn't explicitly try it with glib versions before they changed 
the signal handling in commit 2e471acf, but it *should* work with 
versions before the change. As you can see in the patch, it 
essentially just makes Emacs more aggressive in taking over the 
signal handler and in glib versions before 2e471acf, 
g_source_unref (source) wouldn't result in glib resetting the 
signal handler to SIG_DFL, in which case Emacs will just install 
itself twice to handle SIGCHLD which is fine.

I think commit 2e471acf got added to glib with version 2.37.5 
which was released over 7 years ago.
 

Re: [PATCH] Interferences between xwidgets and async processes?

[JIANG Shaojian]

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

Hi,

I just built emacs 28 with the lasted source, and it seems that this bug
reappears.
Since I have not updated emacs for a long time, I am not sure when it came
back.
I checked xwidget.c and previous fix is still there.

The testing environment and the way to reproduce it is the same as before.

Hopefully someone can confirm this.
Thanks!


Akira Kyle <ak@akirakyle.com> 于2020年11月15日周日 上午3:53写道：

>
> On Sat, Nov 14, 2020 at 09:22 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> >> > The attached patch fixes this but only in a temporary way.
> >>
> >> Thanks; applied to Emacs 28.
> >
> > Just to be sure: the fix that is now installed on master does
> > support
> > current and old versions of Glib, where the old code seemed to
> > work?
> > Or does it break with older Glib versions?
>
> I didn't explicitly try it with glib versions before they changed
> the signal handling in commit 2e471acf, but it *should* work with
> versions before the change. As you can see in the patch, it
> essentially just makes Emacs more aggressive in taking over the
> signal handler and in glib versions before 2e471acf,
> g_source_unref (source) wouldn't result in glib resetting the
> signal handler to SIG_DFL, in which case Emacs will just install
> itself twice to handle SIGCHLD which is fine.
>
> I think commit 2e471acf got added to glib with version 2.37.5
> which was released over 7 years ago.
>
>

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

Re: [PATCH] Interferences between xwidgets and async processes?

[JIANG Shaojian]

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

Hi,

WIth previous patch, I just noticed a message generated by xwidget saying
"Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you
want WebKit to use a different signal".
I did a bit of search and found out that this might be related to a recent
version of libwebkit2gtk (see a similar message in
https://github.com/vertcoin-project/one-click-miner-vnext/issues/271).

The current version of the library on my ubuntu is 2.32. I tried to
downgrade it to an earlier version available, which is 2.28 and the
issue is gone.
So it seems that the updated library breaks previous fix.
Further debugging is beyond my expertise. Hopefully the above information
is useful.

Thanks.


JIANG Shaojian <sdycjsj@gmail.com> 于2021年7月30日周五 上午10:55写道：

> Hi,
>
> I just built emacs 28 with the lasted source, and it seems that this bug
> reappears.
> Since I have not updated emacs for a long time, I am not sure when it came
> back.
> I checked xwidget.c and previous fix is still there.
>
> The testing environment and the way to reproduce it is the same as before.
>
> Hopefully someone can confirm this.
> Thanks!
>
>
> Akira Kyle <ak@akirakyle.com> 于2020年11月15日周日 上午3:53写道：
>
>>
>> On Sat, Nov 14, 2020 at 09:22 AM, Eli Zaretskii <eliz@gnu.org>
>> wrote:
>>
>> >> > The attached patch fixes this but only in a temporary way.
>> >>
>> >> Thanks; applied to Emacs 28.
>> >
>> > Just to be sure: the fix that is now installed on master does
>> > support
>> > current and old versions of Glib, where the old code seemed to
>> > work?
>> > Or does it break with older Glib versions?
>>
>> I didn't explicitly try it with glib versions before they changed
>> the signal handling in commit 2e471acf, but it *should* work with
>> versions before the change. As you can see in the patch, it
>> essentially just makes Emacs more aggressive in taking over the
>> signal handler and in glib versions before 2e471acf,
>> g_source_unref (source) wouldn't result in glib resetting the
>> signal handler to SIG_DFL, in which case Emacs will just install
>> itself twice to handle SIGCHLD which is fine.
>>
>> I think commit 2e471acf got added to glib with version 2.37.5
>> which was released over 7 years ago.
>>
>>

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

Re: [PATCH] Interferences between xwidgets and async processes?

[Lars Ingebrigtsen]

JIANG Shaojian <sdycjsj@gmail.com> writes:

> The current version of the library on my ubuntu is 2.32. I tried to downgrade
> it to an earlier version available, which is 2.28 and the issue is gone. 
> So it seems that the updated library breaks previous fix.

Could you possibly file a bug report about his issue?

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

Re: [PATCH] Interferences between xwidgets and async processes?

[Akira Kyle]

On Sat, Nov 14, 2020 at 08:43 AM, Lars Ingebrigtsen 
<larsi@gnus.org> wrote:

>> The attached patch fixes this but only in a temporary way.
>
> Thanks; applied to Emacs 28.  (I counted non-comment lines, and 
> we're
> still just below the number of lines before we need an FSF 
> copyright
> assignment.  I forget whether I've asked this before -- would 
> you be
> willing to sign such paperwork, so that future patches can be 
> applied?)

Yes, I'd be willing sign the copyright assignment.

>> I think that this should ultimately be fixed in glib by making 
>> it be a
>> better signal handling citizen and do what Emacs does by saving 
>> any
>> existing signal handler and call it from its own signal 
>> handler. I
>> suppose I might be able to send them a patch if that seems like 
>> the
>> best course of action here.
>>
>> [1] https://gitlab.gnome.org/GNOME/glib/-/issues/733
>
> Yes, I think having a fix on the glib side sounds like the only
> workeable long-term solution.

I'll try to raise an issue and perhaps patch with glib when I get 
the chance then.

Re: [PATCH] Interferences between xwidgets and async processes?

[Lars Ingebrigtsen]

Akira Kyle <ak@akirakyle.com> writes:

> Yes, I'd be willing sign the copyright assignment.

Great; here's the form to get started:

-----

Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]

Re: [PATCH] Interferences between xwidgets and async processes?

[JIANG Shaojian]

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

Thanks for the patch. I can also confirm that it fixes the problem.

Akira Kyle <ak@akirakyle.com> 于 2020年11月6日周五 04:27写道：

>
> On Thu, Oct 29, 2020 at 08:23 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> >> Using "top", I can see that the status of the process is "Z".
> >
> > Which AFAIU means that the process indeed exited, but our
> > sentinel was
> > not called, and we therefore didn't yet request the process's
> > exit
> > status.
> >
> > Is it possible that xwidgets somehow block SIGCHLD, or cause us
> > to
> > miss it?
>
>
> Its seems like this is what is happening. The relevant glib
> function which sets up the SIGCHLD signal handler is
> ref_unix_signal_handler_unlocked. It doesn't respect existing
> signal handlers like Emacs does in catch_child_signal and call
> them after it's own handling hence the need for the hack in
> init_process_emacs (process.c) that forces glib to not catch
> SIGCHLD. Setting a breakpoint on ref_unix_signal_handler_unlocked
> the backtrace:
>
> #0  0x0000fffff704b66c in ref_unix_signal_handler_unlocked () from
>
>  /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libglib-2.0.so.0
> #1  0x0000fffff704b8f0 in g_child_watch_source_new () from
>
>  /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libglib-2.0.so.0
> #2  0x0000fffff725a6b4 in initable_init () from
>
>  /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libgio-2.0.so.0
> #3  0x0000fffff72596b0 in g_subprocess_launcher_spawnv () from
>
>  /nix/store/y7i19b8kyif8nqq47xvjxcv2rrd2qca0-glib-2.64.5/lib/libgio-2.0.so.0
> #4  0x0000ffffc906707c in WebKit::ProcessLauncher::launchProcess()
>  () from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #5  0x0000ffffc8eea1d0 in WebKit::AuxiliaryProcessProxy::connect()
>  () from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #6  0x0000ffffc8f45660 in
>  WebKit::WebProcessProxy::create(WebKit::WebProcessPool&,
>  WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::IsPrewarmed,
>  WebKit::WebProcessProxy::ShouldLaunchProcess) ()
>    from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #7  0x0000ffffc8f64bb4 in
>  WebKit::WebProcessPool::createNewWebProcess(WebKit::WebsiteDataStore*,
>  WebKit::WebProcessProxy::IsPrewarmed) ()
>    from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #8  0x0000ffffc8f6b740 in
>  WebKit::WebProcessPool::processForRegistrableDomain(WebKit::WebsiteDataStore&,
>
>  WebKit::WebPageProxy*, WebCore::RegistrableDomain const&) ()
>    from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #9  0x0000ffffc8f6b844 in
>  WebKit::WebPageProxy::launchProcess(WebCore::RegistrableDomain
>  const&, WebKit::WebPageProxy::ProcessLaunchReason) ()
>    from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #10 0x0000ffffc8f6de3c in
>  WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&,
>  WebCore::ShouldOpenExternalURLsPolicy, API::Object*) ()
>    from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #11 0x0000ffffc9006c70 in webkit_web_view_load_uri () from
>
>  /nix/store/g197syqpsd3n2qb460i37lif4qhw6a6k-webkitgtk-2.28.4/lib/libwebkit2gtk-4.0.so.37
> #12 0x0000ffffd684c528 in ?? () from
>  /run/user/1001/webkitgtk-module.soxgSF5U.so
> #13 0x000000000056eadc in funcall_module (function=0x3c97cf5,
>  nargs=2, arglist=0xffffffff3110) at emacs-module.c:1186
> #14 0x0000000000545180 in funcall_lambda (fun=fun@entry=0x2a90,
>  nargs=nargs@entry=2, arg_vector=0xffffffff20f0,
>  arg_vector@entry=0xffffffff3110) at eval.c:3083
> #15 0x0000000000544570 in apply_lambda (fun=0x2a90,
>  fun@entry=0x3c97cf5, args=<optimized out>, count=count@entry=24)
>  at eval.c:3021
> #16 0x00000000005447cc in eval_sub (form=<optimized out>) at
>  eval.c:2424
> #17 0x0000000000544dbc in Fprogn (body=0x0) at eval.c:471
> #18 0x0000000000545048 in funcall_lambda (fun=<optimized out>,
>  nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xffffffff33e0)
>  at lisp.h:1426
> #19 0x000000000054274c in Ffuncall (nargs=nargs@entry=3,
>  args=args@entry=0xffffffff33d8) at eval.c:2888
> #20 0x000000000053f248 in Ffuncall_interactively (nargs=3,
>  args=0xffffffff33d8) at callint.c:253
> #21 0x0000000000542870 in Ffuncall (nargs=nargs@entry=4,
>  args=args@entry=0xffffffff33d0) at lisp.h:2091
> #22 0x0000000000542b70 in Fapply (nargs=nargs@entry=3,
>  args=0xffffffff3570, args@entry=0xffffffff3660) at eval.c:2502
> #23 0x00000000005405e4 in Fcall_interactively
>  (function=0xffffffff3730, record_flag=0xffffffff3630,
>  keys=0x57d418 <exec_byte_code+736>) at lisp.h:1008
> #24 0x0000fffff27262d0 in
>  F636f6d6d616e642d65786563757465_command_execute_0 ()
>    from
>
>  /home/akyle/git/emacs/src/../native-lisp/28.0.50-aarch64-unknown-linux-gnu-08c187d985df753847bb1095eac8e39c/simple-fab5b0cffee734040ac60e9bc557cd20-fad2d213fe4820237be2ea92815644a6.eln
> #25 0x0000000000542870 in Ffuncall (nargs=<optimized out>,
>  args=args@entry=0xffffffff36a0) at lisp.h:2091
> #26 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0x406, nargs=nargs@entry=1, args=<optimized out>,
>  args@entry=0xffffffff3868)
>     at bytecode.c:632
> #27 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff3868, nargs=1, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #28 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=1,
>  arg_vector=arg_vector@entry=0xffffffff3868) at eval.c:3077
> #29 0x000000000054274c in Ffuncall (nargs=2,
>  args=args@entry=0xffffffff3860) at eval.c:2888
> #30 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0x2, nargs=nargs@entry=0, args=<optimized out>,
>  args@entry=0xffffffff3ad0)
>     at bytecode.c:632
> #31 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff3ad0, nargs=0, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #32 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=0,
>  arg_vector=arg_vector@entry=0xffffffff3ad0) at eval.c:3077
> #33 0x000000000054274c in Ffuncall (nargs=1,
>  args=args@entry=0xffffffff3ac8) at eval.c:2888
> #34 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0xa0a, nargs=nargs@entry=16, args=<optimized out>,
>  args@entry=0xffffffff3fc8)
>     at bytecode.c:632
> #35 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff3fc8, nargs=16, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #36 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=16,
>  arg_vector=arg_vector@entry=0xffffffff3fc8) at eval.c:3077
> #37 0x000000000054274c in Ffuncall (nargs=nargs@entry=17,
>  args=args@entry=0xffffffff3fc0) at eval.c:2888
> #38 0x0000000000542b70 in Fapply (nargs=<optimized out>,
>  args=0xffffffff4150) at eval.c:2502
> #39 0x0000000000542870 in Ffuncall (nargs=<optimized out>,
>  args=args@entry=0xffffffff4148) at lisp.h:2091
> #40 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0x606, nargs=nargs@entry=17, args=<optimized out>,
>  args@entry=0xffffffff4298)
>     at bytecode.c:632
> #41 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff4298, nargs=17, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #42 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=17,
>  arg_vector=arg_vector@entry=0xffffffff4298) at eval.c:3077
> #43 0x000000000054274c in Ffuncall (nargs=nargs@entry=18,
>  args=args@entry=0xffffffff4290) at eval.c:2888
> #44 0x0000000000542b70 in Fapply (nargs=<optimized out>,
>  args=0xffffffff4418) at eval.c:2502
> #45 0x0000000000542870 in Ffuncall (nargs=<optimized out>,
>  args=args@entry=0xffffffff4410) at lisp.h:2091
> #46 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0x202, nargs=nargs@entry=16, args=<optimized out>,
>  args@entry=0xffffffff4570)
>     at bytecode.c:632
> #47 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff4570, nargs=16, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #48 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=16,
>  arg_vector=arg_vector@entry=0xffffffff4570) at eval.c:3077
> #49 0x000000000054274c in Ffuncall (nargs=17,
>  args=args@entry=0xffffffff4568) at eval.c:2888
> #50 0x000000000057d418 in exec_byte_code (bytestr=<optimized out>,
>  vector=<optimized out>, maxdepth=<optimized out>,
>  args_template=0x402, nargs=nargs@entry=0, args=<optimized out>,
>  args@entry=0xffffffff4950)
>     at bytecode.c:632
> #51 0x0000000000545130 in fetch_and_exec_byte_code
>  (args=0xffffffff4950, nargs=0, syms_left=<optimized out>,
>  fun=<optimized out>) at lisp.h:1838
> #52 funcall_lambda (fun=<optimized out>, nargs=nargs@entry=0,
>  arg_vector=arg_vector@entry=0xffffffff4950) at eval.c:3077
> #53 0x000000000054274c in Ffuncall (nargs=nargs@entry=1,
>  args=args@entry=0xffffffff4948) at eval.c:2888
> #54 0x000000000053f248 in Ffuncall_interactively (nargs=1,
>  args=0xffffffff4948) at callint.c:253
> #55 0x0000000000542870 in Ffuncall (nargs=nargs@entry=2,
>  args=args@entry=0xffffffff4940) at lisp.h:2091
> #56 0x0000000000542c1c in Fapply (nargs=nargs@entry=3,
>  args=0xffffffff4940, args@entry=0xffffffff4a30) at eval.c:2455
> #57 0x00000000005405e4 in Fcall_interactively
>  (function=0xffffffff4a60, record_flag=0xffffffff4a00,
>  keys=0x542950 <call1+56>) at lisp.h:1008
> #58 0x0000fffff27262d0 in
>  F636f6d6d616e642d65786563757465_command_execute_0 ()
>    from
>
>  /home/akyle/git/emacs/src/../native-lisp/28.0.50-aarch64-unknown-linux-gnu-08c187d985df753847bb1095eac8e39c/simple-fab5b0cffee734040ac60e9bc557cd20-fad2d213fe4820237be2ea92815644a6.eln
> #59 0x0000000000542870 in Ffuncall (nargs=nargs@entry=2,
>  args=args@entry=0xffffffff4a88) at lisp.h:2091
> #60 0x0000000000542950 in call1 (fn=fn@entry=0x42c0,
>  arg1=<optimized out>) at eval.c:2732
> #61 0x00000000004dc4b8 in command_loop_1 () at lisp.h:1008
> #62 0x00000000005419b8 in internal_condition_case
>  (bfun=bfun@entry=0x4dc100 <command_loop_1>,
>  handlers=handlers@entry=0x90, hfun=hfun@entry=0x4d1518
>  <cmd_error>) at eval.c:1365
> #63 0x00000000004cded8 in command_loop_2 (ignore=ignore@entry=0x0)
>  at lisp.h:1008
> #64 0x000000000054191c in internal_catch (tag=tag@entry=0xe040,
>  func=func@entry=0x4cdea8 <command_loop_2>, arg=arg@entry=0x0) at
>  eval.c:1126
> #65 0x00000000004cde74 in command_loop () at lisp.h:1008
> #66 0x00000000004d108c in recursive_edit_1 () at keyboard.c:718
> #67 0x00000000004d143c in Frecursive_edit () at keyboard.c:790
> #68 0x000000000041f0c4 in main (argc=<optimized out>,
>  argv=<optimized out>) at emacs.c:2095
>
> So it seems webkitgtk's use of GSubprocess is what is causing glib
> to take back control of the SIGCHLD sigaction and thus Emacs never
> receives it. Specifically this is the troublesome section (line
> 590 in glib/gio 2.64.5 gsubprocess.c)
>
> /* Start attempting to reap the child immediately */
> if (success)
> {
>     GMainContext *worker_context;
>     GSource *source;
>
>     worker_context = GLIB_PRIVATE_CALL (g_get_worker_context) ();
>     source = g_child_watch_source_new (self->pid);
>     g_source_set_callback (source, (GSourceFunc)
>     g_subprocess_exited, g_object_ref (self), g_object_unref);
>     g_source_attach (source, worker_context);
>     g_source_unref (source);
> }
>
> This ends up calling ref_unix_signal_handler_unlocked in gmain.c
> which installs its own signal handler and glib doesn't restore the
> previous signal handler when its done
> unref_unix_signal_handler_unlocked. This issue was brought up on
> the GNOME mailing lists but it doesn't look like anyone responded
> [1].
>
> We can just handle restoring the signal handler ourselves with the
> attached patch.
>
>
> [1]
> https://mail.gnome.org/archives/gtk-devel-list/2016-October/msg00015.html
>
>

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