From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#58956: mark_object, mark_objects(?) crash Date: Fri, 04 Nov 2022 21:03:47 +0000 Message-ID: References: <874jvi5edp.fsf@melete.silentflame.com> <20221103030046.GA57325@zira.vinc17.org> <83o7to8rh1.fsf@gnu.org> <20221103101308.GD9442@zira.vinc17.org> <83zgd872q2.fsf@gnu.org> <83zgd75hll.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7612"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 58956@debbugs.gnu.org, Paul Eggert , vincent@vinc17.net, 1017711@bugs.debian.org, spwhitton@spwhitton.name To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 04 22:12:46 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 1or3za-0001l4-5O for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Nov 2022 22:12:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1or3yK-0005dw-75; Fri, 04 Nov 2022 17:11:28 -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 1or3s6-0001jk-QG for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 17:05:02 -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 1or3s6-0006Wt-7Y for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 17:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1or3s5-0006ct-Mh for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 17:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2022 21:05: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.166759584525401 (code B ref 58956); Fri, 04 Nov 2022 21:05:01 +0000 Original-Received: (at 58956) by debbugs.gnu.org; 4 Nov 2022 21:04:05 +0000 Original-Received: from localhost ([127.0.0.1]:54948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1or3rB-0006bd-8b for submit@debbugs.gnu.org; Fri, 04 Nov 2022 17:04:05 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:55360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1or3r6-0006bA-1M for 58956@debbugs.gnu.org; Fri, 04 Nov 2022 17:04:03 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2A4L3lN4022265 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 4 Nov 2022 21:03:48 GMT In-Reply-To: <83zgd75hll.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Nov 2022 09:00:54 +0200") 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:247106 Archived-At: Eli Zaretskii writes: >> 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. Sorry I missed those traces. Okay so for both cases if libgccjit is not involved the behaviour of Emacs here is just the plain one and should not be related to native compilation. It's just that native compilation makes it more likely to be identify this condition. >> 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? To me yes. > 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? I think we have no special handling for this case, so yeah we might leave some traces of the compilation. Other than the .eln we should also remove the lisp file we write to be loaded by the async compilation process. I'm not sure where and how would be best to handle all of this tho. Best Regards Andrea