From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interferences between xwidgets and async processes? Date: Thu, 05 Nov 2020 13:27:45 -0700 Message-ID: <86sg9nsg5a.fsf@akirakyle.com> References: <87mu06wyfb.fsf@gnus.org> <83tuuecrl5.fsf@gnu.org> <83v9etaz6z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17245"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: JIANG Shaojian , larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 05 21:28:40 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kals8-0004Dm-No for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 21:28:40 +0100 Original-Received: from localhost ([::1]:41728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kals7-0006lI-KK for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 15:28:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kalrM-0006JV-0I for emacs-devel@gnu.org; Thu, 05 Nov 2020 15:27:52 -0500 Original-Received: from mail-ot1-f67.google.com ([209.85.210.67]:36711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kalrJ-0007Ai-Ga; Thu, 05 Nov 2020 15:27:51 -0500 Original-Received: by mail-ot1-f67.google.com with SMTP id 32so2680601otm.3; Thu, 05 Nov 2020 12:27:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=cHRmfGofpr0vxYnLBGPu9uwR8Rc/8qHYEoqsfYqIC5I=; b=UH/rZVWvIrX+BTKJL+ok+Gv2Ai2xoALmqg9Muhdk3xp8FP4j++BEeGy6LATY6BtxyE WWTkRR9m6OxpSgm+uRBFgZKpr9i0lM+OwGoNk3QL0rtFDF8LP4kX0GBl3+rF+NeA6nSj Jw4yzc2svxvtZf2LDN4J1HNBdJ1lu8Xpx4Mvbzm8hUCeqrhOudgbGEDdhrfVzO6viwXL u5eYRDixHQvi+9rt7Qedd5TbdaSldSrVn9KwCzq2iw6Rw80VIHIRAFpr5ae39JTyLHez o2Gt4bxFj3geWZR+TyP+H9cDx22/emmdZvn+ChPSedL3AdLY7eGRGlLmZ2FfwjrGIDvL 1Ipg== X-Gm-Message-State: AOAM5329SuaFFpuPhXe78ASYjuIdRcCdq6f8COBJD7XB/sqbSi5fnU91 2mlgF/SmIFgW7/U0A973oHCobtCSHhkM/g== X-Google-Smtp-Source: ABdhPJzSed9YCxy1d2cGtwVUye8E/zwPKqDfIM48n0LhoSRzinwSpExE5OtOw7f60nWpmOnD8zpNSw== X-Received: by 2002:a9d:65d5:: with SMTP id z21mr2663625oth.251.1604608067386; Thu, 05 Nov 2020 12:27:47 -0800 (PST) Original-Received: from data (c-67-162-131-131.hsd1.co.comcast.net. [67.162.131.131]) by smtp.gmail.com with ESMTPSA id k15sm584472oor.11.2020.11.05.12.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2020 12:27:46 -0800 (PST) In-reply-to: <83v9etaz6z.fsf@gnu.org> Received-SPF: pass client-ip=209.85.210.67; envelope-from=aikokyle@gmail.com; helo=mail-ot1-f67.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/05 15:27:48 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258757 Archived-At: --=-=-= Content-Type: text/plain; format=flowed On Thu, Oct 29, 2020 at 08:23 AM, Eli Zaretskii 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=, count=count@entry=24) at eval.c:3021 #16 0x00000000005447cc in eval_sub (form=) at eval.c:2424 #17 0x0000000000544dbc in Fprogn (body=0x0) at eval.c:471 #18 0x0000000000545048 in funcall_lambda (fun=, 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 ) 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=, args=args@entry=0xffffffff36a0) at lisp.h:2091 #26 0x000000000057d418 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=0x406, nargs=nargs@entry=1, args=, args@entry=0xffffffff3868) at bytecode.c:632 #27 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff3868, nargs=1, syms_left=, fun=) at lisp.h:1838 #28 funcall_lambda (fun=, 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=, vector=, maxdepth=, args_template=0x2, nargs=nargs@entry=0, args=, args@entry=0xffffffff3ad0) at bytecode.c:632 #31 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff3ad0, nargs=0, syms_left=, fun=) at lisp.h:1838 #32 funcall_lambda (fun=, 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=, vector=, maxdepth=, args_template=0xa0a, nargs=nargs@entry=16, args=, args@entry=0xffffffff3fc8) at bytecode.c:632 #35 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff3fc8, nargs=16, syms_left=, fun=) at lisp.h:1838 #36 funcall_lambda (fun=, 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=, args=0xffffffff4150) at eval.c:2502 #39 0x0000000000542870 in Ffuncall (nargs=, args=args@entry=0xffffffff4148) at lisp.h:2091 #40 0x000000000057d418 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=0x606, nargs=nargs@entry=17, args=, args@entry=0xffffffff4298) at bytecode.c:632 #41 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff4298, nargs=17, syms_left=, fun=) at lisp.h:1838 #42 funcall_lambda (fun=, 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=, args=0xffffffff4418) at eval.c:2502 #45 0x0000000000542870 in Ffuncall (nargs=, args=args@entry=0xffffffff4410) at lisp.h:2091 #46 0x000000000057d418 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=0x202, nargs=nargs@entry=16, args=, args@entry=0xffffffff4570) at bytecode.c:632 #47 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff4570, nargs=16, syms_left=, fun=) at lisp.h:1838 #48 funcall_lambda (fun=, 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=, vector=, maxdepth=, args_template=0x402, nargs=nargs@entry=0, args=, args@entry=0xffffffff4950) at bytecode.c:632 #51 0x0000000000545130 in fetch_and_exec_byte_code (args=0xffffffff4950, nargs=0, syms_left=, fun=) at lisp.h:1838 #52 funcall_lambda (fun=, 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 ) 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=) at eval.c:2732 #61 0x00000000004dc4b8 in command_loop_1 () at lisp.h:1008 #62 0x00000000005419b8 in internal_condition_case (bfun=bfun@entry=0x4dc100 , handlers=handlers@entry=0x90, hfun=hfun@entry=0x4d1518 ) 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 , 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=, argv=) 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 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Fix-xwidget-s-webkitgtk-widget-overriding-of-Emacs-S.patch Content-Description: xwidget patch >From 54c0cfdba0ae036cfca6083154ed52f7e2499174 Mon Sep 17 00:00:00 2001 From: Akira Kyle 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 --=-=-=--