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#46502: 28.0.50; [feature/native-comp] (d3a399dd) native-comp bootstrap failure Date: Fri, 19 Feb 2021 15:48:10 +0200 Message-ID: <83ft1s2mp1.fsf@gnu.org> References: <87o8gn8ciy.fsf@md5i.com> <83h7m95tt2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1422"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mwd@md5i.com, 46502@debbugs.gnu.org, akrl@sdf.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 19 14:51:08 2021 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 1lD6BX-0000Fh-OD for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Feb 2021 14:51:07 +0100 Original-Received: from localhost ([::1]:45968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD6BW-0003cy-L6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Feb 2021 08:51:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD69W-0002Rx-Mh for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 08:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lD69W-0003qi-Em for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 08:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lD69W-0001op-CQ for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 08:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Feb 2021 13:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46502 X-GNU-PR-Package: emacs Original-Received: via spool by 46502-submit@debbugs.gnu.org id=B46502.16137424856925 (code B ref 46502); Fri, 19 Feb 2021 13:49:02 +0000 Original-Received: (at 46502) by debbugs.gnu.org; 19 Feb 2021 13:48:05 +0000 Original-Received: from localhost ([127.0.0.1]:48970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD68a-0001nc-Ef for submit@debbugs.gnu.org; Fri, 19 Feb 2021 08:48:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD68Y-0001n8-UT for 46502@debbugs.gnu.org; Fri, 19 Feb 2021 08:48:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47435) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD68S-0003MG-C3; Fri, 19 Feb 2021 08:47:56 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2866 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lD68R-0003Kf-9c; Fri, 19 Feb 2021 08:47:56 -0500 In-Reply-To: (message from Pip Cet on Fri, 19 Feb 2021 13:31:49 +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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:200331 Archived-At: > From: Pip Cet > Date: Fri, 19 Feb 2021 13:31:49 +0000 > Cc: akrl@sdf.org, mwd@md5i.com, 46502@debbugs.gnu.org > > > > One thing I've noticed in my experiments is that many builds that are > > > interrupted at the wrong point and then resumed produce different > > > results. I.e. you type "make", then hit Ctrl-C at the wrong time, then > > > type "make" again and you get a different result. > > > > What does "different result" mean in this case? is the produced .eln > > file different? or something else? > > There are differences both in the .elc and .eln, and I saw different > success/failure behavior but only with local modifications. Let's talk about *.elc files first, as this is not supposed to happen. AFAIR, we write the bytecode into a temporary file, and then rename it atomically only when the compilation finishes successfully. So interrupting should not do any harm, and therefore I'm curious what kind of differences in *.elc files do you see in these cases. > It's possible that this is all harmless, but I have the bad habit of > assuming I can just type "make" again and have it resume an > interrupted build, and that certainly does not work on the > native-comp branch (I'm not sure it works on the master branch). I'd suggest to start with master, as that is supposed to be much more mature. If that turns out to work correctly (and (IME it is), then we could take a look at the native-comp branch, where there could be problems we didn't yet fix. In general, Make itself will delete any target files it knows about that were not fully built at the time of SIGINT. Maybe we don't tell Make enough about the files native-comp produces? > > > BTW, I'm also seeing very deep recursion when building the nativecomp > > > branch > > How do you see that? > > Stack overflows in a limited-stack environment, even with the GC code > modified to allocate stack space more efficiently. > > > And what code recurses so deeply? > > Unfortunately, the environment I'm playing with doesn't have very good > backtrace facilities. (This is WebAssembly run by the Mozilla jsshell, > which has a small-ish stack size limit. I'll try finding what limits > the reported backtrace depth and disabling it.) I think it'd be interesting to know what code overflows the stack, if it isn't GC.