From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Nelson Newsgroups: gmane.emacs.bugs Subject: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Date: Thu, 6 May 2021 12:26:12 +0200 Message-ID: References: <87a6pd45w6.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003338d405c1a6be0d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34490"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 06 17:07:04 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 1lefag-0008oA-Hi for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 May 2021 17:07:02 +0200 Original-Received: from localhost ([::1]:45218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lefaf-0006aV-KF for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 May 2021 11:07:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lefYk-00058I-Ho for bug-gnu-emacs@gnu.org; Thu, 06 May 2021 11:05:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54649) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lefYk-0000oh-7g for bug-gnu-emacs@gnu.org; Thu, 06 May 2021 11:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lefYk-0001dM-1s for bug-gnu-emacs@gnu.org; Thu, 06 May 2021 11:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Nelson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 May 2021 15:05:01 +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.16203134556258 (code B ref 48100); Thu, 06 May 2021 15:05:01 +0000 Original-Received: (at 48100) by debbugs.gnu.org; 6 May 2021 15:04:15 +0000 Original-Received: from localhost ([127.0.0.1]:37959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lefXy-0001cs-GM for submit@debbugs.gnu.org; Thu, 06 May 2021 11:04:15 -0400 Original-Received: from mail-pl1-f174.google.com ([209.85.214.174]:42968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lebDB-0006SP-AA for 48100@debbugs.gnu.org; Thu, 06 May 2021 06:26:30 -0400 Original-Received: by mail-pl1-f174.google.com with SMTP id v13so3147576ple.9 for <48100@debbugs.gnu.org>; Thu, 06 May 2021 03:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MBZd+jWnkqgAro9aNTAEJvuZ6DutRODheAjw707dg1M=; b=sYvmObGiET1p1lBkKj3yjkkN+dXVPUzG0sjyHDsykLqygU2258ld440xizZ/7kyMzY pkXIBAQ1kfG2GY62l/YB46b7pvuUDMndXy3JyUK0QOvdSOZn2OThW2GHucYc5fPJj9+2 TWY9/WM/Js/4DfEMvgr4EU4g5OZ611Mk/WlU639OE5kVdTDp4+zBneyDm4YGbycGYkM9 C0CVNcurvCz3l85XhFpqsrd//p+6KBPd6PLK/R2RPnYLubNjOwGcuvAQfzs3MPZ5Ak6s knzS1mbjDYlpBZEMtdU3Gcf8LZjeJ7qPHzq1gD8h9AFCvTxepNJb4gLy+lQWztkLHKKK SmiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MBZd+jWnkqgAro9aNTAEJvuZ6DutRODheAjw707dg1M=; b=IUMbr19oU42fot4D6iuXr2I4/J44zj8QXJ6COWu1ym1fpSVqxYKm9nxfY81Wi2+zRf OY1FLiKLE1005MoswlF071ng9220VcVwQ5vRqf4uV8Apu6OdRu3UetE1byWcoei1L38z eAgx0XZMxx9KofOZvGisMENo9GUVSDOSWwWh3rSum314OmKvJcezCeoWPVLISYY6Dsyj vc8BCBfHgnYMu23hVNnECFkKt0+AVLG8XjIjVl/hzkWCOvYXOFjHVQE4q9YG7nroSGuC R7VMLJFiv5eeFrz4tdrj0MQc/oNcmMRrhK6ct5SwHNiBfW0PaLUa0/E4mfgoGkOhIKMM LWYg== X-Gm-Message-State: AOAM531OyZrQHVJBmsBE5F9xtIzNX/vPc/wssnhuOHRT0oCJxHzC7oja V0oHshyxyZFLLh29ntKRZY9wp2S23Hdjnm3z4C4= X-Google-Smtp-Source: ABdhPJwGvjpFCrMLKW3uHFnPWAF2UIhDbOmiz9Fz0JDwxP8rmi5jh91GpD1pfaoWxi5V38P3ZGhLqzNinbqoxPiwcBA= X-Received: by 2002:a17:902:ed97:b029:ee:af8e:3a0a with SMTP id e23-20020a170902ed97b02900eeaf8e3a0amr3935140plj.52.1620296783312; Thu, 06 May 2021 03:26:23 -0700 (PDT) In-Reply-To: X-Mailman-Approved-At: Thu, 06 May 2021 11:04:12 -0400 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:205843 Archived-At: --0000000000003338d405c1a6be0d Content-Type: text/plain; charset="UTF-8" Hi Alan, Looks good after updating -- seems like it was indeed a repeat of #48061. Thanks for your help! I'll report back if anything similar comes up again. Paul On Wed, May 5, 2021 at 12:18 PM Alan Mackenzie wrote: > 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). > --0000000000003338d405c1a6be0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

Looks good after updating -- s= eems like it was indeed a repeat of #48061.=C2=A0 Thanks for your help!=C2= =A0 I'll report back if anything similar comes up again.

=
Paul


On Wed, May 5, 2021 at 12:18 PM Alan Ma= ckenzie <acm@muc.de> wrote:
Hello, Paul.

On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote:
> Hi all,

> Thanks for your responses.=C2=A0 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 functio= n
> c-determine-limit-no-macro before doing anything.=C2=A0 What baffles m= e is why
> that function should behave differently after C-M-x'ing (perhaps s= omething
> to do with emacs compilation, which I'm not so familiar with).

I'm glad you put so much work into debugging this.=C2=A0 What you have<= br> probably done is found bug #48061 again, which saves me a lot of work.
Thanks!=C2=A0 ;-)

In that bug, the native compiler mis-compiled c-determine-limit-no-macro such that it sometimes returned an invalid value nil.=C2=A0 This looks like=
exactly what we are seeing now.=C2=A0 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.=C2=A0 With any luck, the current bug will have bee= n
fixed.=C2=A0 I'm leaving the rest of your last post here, just in case = we
don't yet have a fix.=C2=A0 Would you please let us know how your lates= t test
goes.=C2=A0 Thanks!

> Before diving into the details, let me note that the issue does not ap= pear
> to be an isolated peculiarity related to inserting large chunks of cod= e --
> the same bug has shown up repeatedly the past few days in more "o= rganic"
> situations involving normal C++ code.=C2=A0 The example noted in my or= iginal
> 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:

>=C2=A0 =C2=A0;; CASE 5B: After a function header but before the body (o= r
> ;; the ending semicolon if there's no body).
> ((save-excursion
>=C2=A0 =C2=A0 (when (setq placeholder (c-just-after-func-arglist-p
>=C2=A0 =C2=A0 =C2=A0(max lim (c-determine-limit 500))))
>=C2=A0 =C2=A0 =C2=A0 (setq tmp-pos (point))))
>=C2=A0 (cond

> The issue is that (c-determine-limit 500) returns nil, which is an inv= alid
> argument to ~max~.

> When I instrument and step through the offending invocation of
> c-determine-limit, the execution passes through the second branch of t= he
> final ~cond~ clause, which reads as follows:

> ((>=3D count how-far-back)
>=C2=A0 (c-determine-limit-no-macro
>=C2=A0 (+ (car elt) (- count how-far-back))
>=C2=A0 org-start))

> Stepping through the above code block in edebug using SPC, the functio= n
> c-determine-limit-no-macro returns ~nil~, which then propagates as the=
> return value of c-determine-limit.=C2=A0 The problem boils down to: wh= y 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.=C2=A0 That function is simple enough= to
> analyze with the naked eye, and it seems logically impossible for it t= o
> return nil on non-nil arguments.=C2=A0 When I tried debugging it, the = issue went
> away entirely -- after instrumentation, c-determine-limit-no-macro ret= urns
> a numerical value, as it should, which propagates to a numerical retur= n
> value of c-determine-limit, and hence to an error-free execution of > c-guess-basic-syntax.=C2=A0 This is all with emacs -Q and tested repea= tedly
> across fresh startups of emacs.=C2=A0 I then tried simply C-M-x'in= g
> c-determine-limit-no-macro on startup, and the original issue went awa= y.

> As a "fix", I've simply copied the definition of c-deter= mine-limit-no-macro
> to my init file.=C2=A0 I'd still be happy to understand better wha= t's going on.

> Thanks, best,

> Paul

--
Alan Mackenzie (Nuremberg, Germany).
--0000000000003338d405c1a6be0d--