From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Date: Wed, 5 May 2021 10:18:40 +0000 Message-ID: References: <87a6pd45w6.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14216"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org To: Paul Nelson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 05 12:19:14 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 1leEcc-0003b7-GG for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 May 2021 12:19:14 +0200 Original-Received: from localhost ([::1]:37016 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leEcb-0007sV-G2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 May 2021 06:19:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leEcQ-0007qh-PS for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 06:19:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47680) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1leEcQ-0004wv-Gw for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 06:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1leEcQ-0007YW-Cp for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 06:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 May 2021 10:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48100 X-GNU-PR-Package: emacs Original-Received: via spool by 48100-submit@debbugs.gnu.org id=B48100.162020993129035 (code B ref 48100); Wed, 05 May 2021 10:19:02 +0000 Original-Received: (at 48100) by debbugs.gnu.org; 5 May 2021 10:18:51 +0000 Original-Received: from localhost ([127.0.0.1]:59226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leEcF-0007YF-BR for submit@debbugs.gnu.org; Wed, 05 May 2021 06:18:51 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29895 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1leEcC-0007Y8-1x for 48100@debbugs.gnu.org; Wed, 05 May 2021 06:18:49 -0400 Original-Received: (qmail 35001 invoked by uid 3782); 5 May 2021 10:18:41 -0000 Original-Received: from acm.muc.de (p4fe15dc9.dip0.t-ipconnect.de [79.225.93.201]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 05 May 2021 12:18:40 +0200 Original-Received: (qmail 5232 invoked by uid 1000); 5 May 2021 10:18:40 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:205676 Archived-At: Hello, Paul. On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote: > Hi all, > Thanks for your responses. Alan's suggestion "M-: (def-edebug-spec > c-save-buffer-state let*)" allowed me to debug the original issue in more > detail. > In summary, the issue goes away entirely if I simply C-M-x the function > c-determine-limit-no-macro before doing anything. What baffles me is why > that function should behave differently after C-M-x'ing (perhaps something > to do with emacs compilation, which I'm not so familiar with). I'm glad you put so much work into debugging this. What you have probably done is found bug #48061 again, which saves me a lot of work. Thanks! ;-) In that bug, the native compiler mis-compiled c-determine-limit-no-macro such that it sometimes returned an invalid value nil. This looks like exactly what we are seeing now. Bug #48061 was fixed and closed on Wednesday 28th April, a week ago. Could I ask you, please, to update your Emacs (if you haven't already done so) and rebuild it. With any luck, the current bug will have been fixed. I'm leaving the rest of your last post here, just in case we don't yet have a fix. Would you please let us know how your latest test goes. Thanks! > Before diving into the details, let me note that the issue does not appear > to be an isolated peculiarity related to inserting large chunks of code -- > the same bug has shown up repeatedly the past few days in more "organic" > situations involving normal C++ code. The example noted in my original > report remains the simplest reproducible one that I've found. > The part of c-guess-basic-syntax that generates the error ("Wrong type > argument: number-or-marker-p, nil") is the following: > ;; CASE 5B: After a function header but before the body (or > ;; the ending semicolon if there's no body). > ((save-excursion > (when (setq placeholder (c-just-after-func-arglist-p > (max lim (c-determine-limit 500)))) > (setq tmp-pos (point)))) > (cond > The issue is that (c-determine-limit 500) returns nil, which is an invalid > argument to ~max~. > When I instrument and step through the offending invocation of > c-determine-limit, the execution passes through the second branch of the > final ~cond~ clause, which reads as follows: > ((>= count how-far-back) > (c-determine-limit-no-macro > (+ (car elt) (- count how-far-back)) > org-start)) > Stepping through the above code block in edebug using SPC, the function > c-determine-limit-no-macro returns ~nil~, which then propagates as the > return value of c-determine-limit. The problem boils down to: why does > c-determine-limit-no-macro return ~nil~? > The arguments passed to the function c-determine-limit-no-macro in the > offending invocation are non-nil. That function is simple enough to > analyze with the naked eye, and it seems logically impossible for it to > return nil on non-nil arguments. When I tried debugging it, the issue went > away entirely -- after instrumentation, c-determine-limit-no-macro returns > a numerical value, as it should, which propagates to a numerical return > value of c-determine-limit, and hence to an error-free execution of > c-guess-basic-syntax. This is all with emacs -Q and tested repeatedly > across fresh startups of emacs. I then tried simply C-M-x'ing > c-determine-limit-no-macro on startup, and the original issue went away. > As a "fix", I've simply copied the definition of c-determine-limit-no-macro > to my init file. I'd still be happy to understand better what's going on. > Thanks, best, > Paul -- Alan Mackenzie (Nuremberg, Germany).