From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#58956: mark_object, mark_objects(?) crash Date: Fri, 04 Nov 2022 09:00:54 +0200 Message-ID: <83zgd75hll.fsf__9861.33168205328$1667546350$gmane$org@gnu.org> References: <874jvi5edp.fsf@melete.silentflame.com> <20221103030046.GA57325@zira.vinc17.org> <83o7to8rh1.fsf@gnu.org> <20221103101308.GD9442@zira.vinc17.org> <83zgd872q2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36295"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58956@debbugs.gnu.org, vincent@vinc17.net, 1017711@bugs.debian.org, spwhitton@spwhitton.name To: Andrea Corallo , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 04 08:19:04 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oqqyl-0009DR-Ky for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Nov 2022 08:19:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqqyI-0008P3-Cn; Fri, 04 Nov 2022 03:18:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqiJ-0001UW-1z for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqqiI-0007z4-BN for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqqiI-0008Ji-0p for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2022 07:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58956 X-GNU-PR-Package: emacs Original-Received: via spool by 58956-submit@debbugs.gnu.org id=B58956.166754529931941 (code B ref 58956); Fri, 04 Nov 2022 07:02:01 +0000 Original-Received: (at 58956) by debbugs.gnu.org; 4 Nov 2022 07:01:39 +0000 Original-Received: from localhost ([127.0.0.1]:51473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqqhu-0008J7-NB for submit@debbugs.gnu.org; Fri, 04 Nov 2022 03:01:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55628) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqqhq-0008Ir-IL for 58956@debbugs.gnu.org; Fri, 04 Nov 2022 03:01:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqhj-0007x8-QC; Fri, 04 Nov 2022 03:01:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CqwBkyqh8VF5NHcTfivkMzL2c49PPeMs6sX9AhHrRAc=; b=kVtdAVWuAeEl 1hLezwWdp0KwWnM/snQ+CkX6WU3WlwHK8lfD8hWCjIz9U2W1hRM3l7fvvSDqJ/0I0tugOzmqNOgVY 3+vvz9AgCRf+FoujSskzBw1F+7rxUHMyaf5+NyzjXUs3r8d5At0Szb/i5oFVZeDUIWnLfq3kbB7dH w3bNVVrdC8Joox/VsfOgDCSI6aVFKbJsI2f7F615CiTevYnM9DXqNkM20Y8zm7n3qJQgyhUxGzkTJ 3/f+xdG9si58tnB2NJN4LQdchde5TiyBo/E8oo4mhzadh8c5swbdTegI73N9hqF/nt7CK5bn+f1TQ XNBvUmM9KruVddDUkoKw5w==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqhJ-000336-J2; Fri, 04 Nov 2022 03:01:03 -0400 In-Reply-To: (message from Andrea Corallo on Thu, 03 Nov 2022 21:25:08 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247044 Archived-At: > From: Andrea Corallo > Cc: Vincent Lefevre , spwhitton@spwhitton.name, > 58956@debbugs.gnu.org, 1017711@bugs.debian.org > Date: Thu, 03 Nov 2022 21:25:08 +0000 > > AFAIU the Emacs subprocess we use to compile should behave like a > regular Emacs. Basically, you are saying that if the sub-process that runs async-compilation gets SIGHUP, it should abort and dump core, like a normal Emacs session does, right? The backtrace posted to the Debian bug tracker, here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=5 indicates that Emacs was in the middle of comp-copy-insn which was called from comp-fwprop. Then Emacs performed GC, and SIGHUP was received during GC. IOW, we were in our Lisp code, not in a libgccjit code, when the signal arrived. Another backtrace, posted here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=45 tells a somewhat different story: it doesn't show Emacs in the middle of a native compilation, but just inside substitute-command-keys that was called from command-line. > Now, the only option that comes to my mind is that libgccjit (being > strictly derived from the GCC codebase) might be registering a signal > handler of some kind that alters the behaviour we expect. But if this > is the case we should find trace of it the strace, or we can use gdb > setting a break point into 'signal' as well to check. > > Indeed if this theory is true I think should be classified as a > libgccjit bug. I don't think it's true, see above. Paul, can you help here, please? We need to establish what is the source of SIGHUP in these cases. "These cases" mean, AFAIU, the situations where Emacs launched an async subprocess to do native compilation (which is another Emacs process in a --batch session), and the parent Emacs session is terminated by the user before the async compilation runs to completion. Would the child Emacs process get SIGHUP in this scenario? If yes, then I think we should treat SIGHUP differently in non-interactive invocations: instead of dumping core, we should catch the signal and exit with a non-zero exit status. Does this make sense? Andrea, if we do the above as I suggest, is there any cleanup that we need to do before exiting? For example, what if the subprocess that does the async compilation already started writing the .eln file when the signal arrives? What do we do today when the parent interactive Emacs is terminated by the user?