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
>
>