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#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c Date: Sat, 13 Mar 2021 10:34:06 +0200 Message-ID: <838s6rjvup.fsf@gnu.org> References: <83sg52lykn.fsf@gnu.org> <83mtv8lrmf.fsf@gnu.org> <83czw4lelg.fsf@gnu.org> <835z1wl6ao.fsf@gnu.org> <83zgz8jq7t.fsf@gnu.org> <83pn04jhge.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18110"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47067@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 13 09:35:25 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 1lKzk4-0004aH-68 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Mar 2021 09:35:24 +0100 Original-Received: from localhost ([::1]:47172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKzk2-000353-NE for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Mar 2021 03:35:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKzjj-00034h-Fq for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 03:35:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47515) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lKzjh-0005VH-PZ for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 03:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lKzjh-0002R8-LZ for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 03:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Mar 2021 08:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47067 X-GNU-PR-Package: emacs Original-Received: via spool by 47067-submit@debbugs.gnu.org id=B47067.16156244529308 (code B ref 47067); Sat, 13 Mar 2021 08:35:01 +0000 Original-Received: (at 47067) by debbugs.gnu.org; 13 Mar 2021 08:34:12 +0000 Original-Received: from localhost ([127.0.0.1]:59061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKziu-0002Q3-1H for submit@debbugs.gnu.org; Sat, 13 Mar 2021 03:34:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKzir-0002Pm-8v for 47067@debbugs.gnu.org; Sat, 13 Mar 2021 03:34:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59769) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKzil-0004ws-Ch; Sat, 13 Mar 2021 03:34:03 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2014 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lKzij-0001X7-M7; Sat, 13 Mar 2021 03:34:02 -0500 In-Reply-To: (message from Andrea Corallo on Fri, 12 Mar 2021 20:10:27 +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:202242 Archived-At: > From: Andrea Corallo > Cc: 47067@debbugs.gnu.org > Date: Fri, 12 Mar 2021 20:10:27 +0000 > > >> > Just evaluating c-beginning-of-statement-1 doesn't help. But if I > >> > load cc-engine.el, then the crash goes away. > >> > >> Okay, then probably is one of the other four c-* functions we see in the > >> backtrace. > > > > Yes, but how to determine which one? > > Given they are 4 one could go evaluating these one by one, if they were > more bisection would have been the best strategy. Yeah that's not the > most fun... I was wrong: it _is_ c-beginning-of-statement-1, after all. It's just that the procedure I followed to evaluate is was wrong. AFAIU now, it should be: first load-library cc-engine (which loads the .eln file), then evaluate the function's definition in the .el file. So now, given that this (humongous) function is the suspect, how do I proceed with the next steps, which you described as follows: When the function is identified I typically construct a single function reproducer, for this I typically need the input parameters and I try to substitute all other values coming from the environment with something I can control. This step involves understanding which part of the environment are captured by the function (say: point, current buffer content etc etc...). At that point I reduce the function searching for the minimal piece of code that behaves differently when native compiled. At this point will typically start the "smart" part of the investigation. > >> To force the .elc to be loaded one has to bind `load-no-native' to > >> non-nil. > > > > I think if load-file is invoked interactively, and the user actually > > types "foo.elc", we need to bind load-no-native non-nil > > automatically. Otherwise users would be surprised, as it goes against > > the logic of what we do when the user types "foo.el". > > We certanly can do this if this is what we want. This breaks a little > the idea to have the system as much transparent as possible, I went this > way cause this was my understanding of what we wanted but I've no strong > feeling with that. I don't think this will break the transparent operation, because loading a package non-interactively (as in when the corresponding feature is 'require'd by some code) will still load the .eln file. Only the following 2 use cases will be affected: M-x load-file RET /path/to/FOO.elc RET M-x load-library RET FOO.elc RET IOW, when the user loads the file/library interactively, and explicitly uses the .elc extension, we load the file the user specified, not the corresponding .eln file.