From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pieter van Oostrum Newsgroups: gmane.emacs.bugs Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90 Date: Tue, 10 Mar 2020 19:23:26 +0100 Message-ID: References: <24162.58107.725366.668639@cochabamba.vanoostrum.org> <329e58b1-6255-311e-bdd8-b6f5b3d5208f@cs.ucla.edu> <22225b66-44f6-d132-3036-92181d53c28d@cs.ucla.edu> <89A83582-358F-43DC-B96E-04EE9D655D5F@vanoostrum.org> <63b88e2d-9888-f3ce-a4b0-fcf344e803e5@cs.ucla.edu> <83d09lbgk5.fsf@gnu.org> <83sgig9rg6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="92844"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (darwin) Cc: 39962@debbugs.gnu.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 10 19:24:24 2020 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 1jBjYE-000NwH-Ga for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Mar 2020 19:24:22 +0100 Original-Received: from localhost ([::1]:38242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBjYD-0003Ff-Hq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Mar 2020 14:24:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41067) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBjXw-0003FR-0v for bug-gnu-emacs@gnu.org; Tue, 10 Mar 2020 14:24:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBjXu-0005Cd-Cb for bug-gnu-emacs@gnu.org; Tue, 10 Mar 2020 14:24:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47323) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jBjXu-0005CR-8V for bug-gnu-emacs@gnu.org; Tue, 10 Mar 2020 14:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jBjXu-0000WX-4n for bug-gnu-emacs@gnu.org; Tue, 10 Mar 2020 14:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pieter van Oostrum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Mar 2020 18:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39962 X-GNU-PR-Package: emacs Original-Received: via spool by 39962-submit@debbugs.gnu.org id=B39962.15838646161979 (code B ref 39962); Tue, 10 Mar 2020 18:24:02 +0000 Original-Received: (at 39962) by debbugs.gnu.org; 10 Mar 2020 18:23:36 +0000 Original-Received: from localhost ([127.0.0.1]:53296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBjXT-0000Vr-Iw for submit@debbugs.gnu.org; Tue, 10 Mar 2020 14:23:35 -0400 Original-Received: from smarthost-a.hosting2go.nl ([83.137.198.201]:60146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBjXS-0000VX-0o for 39962@debbugs.gnu.org; Tue, 10 Mar 2020 14:23:34 -0400 X-ASG-Debug-ID: 1583864607-0ac37b15bc248d080001-PyL51Z Original-Received: from server24.hosting2go.nl (server24.hosting2go.nl [185.135.241.24]) by smarthost-a.hosting2go.nl with ESMTP id mxnz2Mhcwo5CWQGu (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <39962@debbugs.gnu.org>; Tue, 10 Mar 2020 19:23:27 +0100 (CET) X-Barracuda-Envelope-From: pieter-l@vanoostrum.org X-Barracuda-Effective-Source-IP: server24.hosting2go.nl[185.135.241.24] X-Barracuda-Apparent-Source-IP: 185.135.241.24 Original-Received: (qmail 7595 invoked from network); 10 Mar 2020 18:23:27 -0000 Original-Received: from static-145.132.212.31.ip.telfort.nl (HELO cochabamba.vanoostrum.org) (145.132.212.31) by server24.hosting2go.nl with SMTP; 10 Mar 2020 18:23:27 -0000 Received-SPF: unknown (server24.hosting2go.nl: domain at 83.137.194.9 does not designate permitted sender hosts) Original-Received: from cochabamba.vanoostrum.org (localhost [IPv6:::1]) by cochabamba.vanoostrum.org (Postfix) with ESMTP id 3A81BAACB511; Tue, 10 Mar 2020 19:23:27 +0100 (CET) X-ASG-Orig-Subj: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90 In-Reply-To: <83sgig9rg6.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Mar 2020 17:10:01 +0200") X-Barracuda-Connect: server24.hosting2go.nl[185.135.241.24] X-Barracuda-Start-Time: 1583864607 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://83.137.198.201:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at hosting2go.nl X-Barracuda-Scan-Msg-Size: 3613 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.5 tests=BSF_SC0_MISMATCH_TO A-X-Hosting2GO-Smarthost: Clean X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80583 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:177154 Archived-At: Eli Zaretskii writes: >> From: Pieter van Oostrum >> Cc: Eli Zaretskii , 39962@debbugs.gnu.org >> Date: Tue, 10 Mar 2020 11:52:04 +0100 >> >> I think we got stuck here. > > I think you are jumping to conclusions too quickly. We've just > obtained the ability of putting GDB to a good use in this case, so we > are just starting to look seriously into this problem. There are > still several things to try before we decide that we are stuck. I meant: in the current session. I have done a recompile with cleaner options. I will start a new session and set the breakpoints/suggestions mentioned below, and then try to have it crash/trigger the bug again. I will keep the other session around as long as my laptop can bear it. >> I don't think the problem is in the actual code that Emacs was >> executing at this point. Rather, the problem was that a marker was >> corrupted (m->charpos == 0). >> That could have happened at a completely unrelated place. I have been >> trying to look in insdel.c and editfns.c to find something unusual, >> but to no avail. >> >> I have also looked into the chain of markers in the buffer. There are >> quite a lot of them, and I haven't finished it, but what I have seen >> looks normal. >> >> On the other hand, every edit action on the buffer must have adjusted >> the markers, so the corruption probably did not occur a long time ago. > > Indeed, so the "completely unrelated code" which corrupts the marker > (if indeed this is what happens) must be quite close to what we see, > perhaps even in the same backtrace. Too early to decide that's not > so. > > Moreover, we don't even know that the code being executed is not the > culprit: it could be a compiler bug, for example. > >> Do you have any suggestion on what more to inspect? > > A few. > > First, your original message indicated that you used the -march > compiler switch -- is that strictly necessary? can Emacs be built with > the default architecture, and if so, does the bug still happen? > > Next, I see two places in the code which assigns the value to > m->charpos without validating it first. Here's one: > > static void > attach_marker (struct Lisp_Marker *m, struct buffer *b, > ptrdiff_t charpos, ptrdiff_t bytepos) > { > /* In a single-byte buffer, two positions must be equal. > Otherwise, every character is at least one byte. */ > if (BUF_Z (b) == BUF_Z_BYTE (b)) > eassert (charpos == bytepos); > else > eassert (charpos <= bytepos); > > m->charpos = charpos; <<<<<<<<<<<<<<<<<<<<< > m->bytepos = bytepos; > > The other one is in alloc.c:build_marker. > > So another idea is to put a conditional breakpoint there: > > (gdb) break marker.c:472 if charpos <= 0 > > and similarly for build_marker, and run with them to see whether you > ever get any of them to break. If one of these breakpoints breaks, we > then will have our culprit. > > The next idea depends on whether the offending marker always happens > in the same buffer and at the same position in the buffer's chain of > markers. For example, is it always the first or the last marker? If > it is, then you could put a watchpoint on that marker's charpos, > conditioned by the value being zero, and see if you can catch the code > which does that. > > That's what I have for now. I will try to come up with more ideas > later. > > Thanks. -- Pieter van Oostrum www: http://pieter.vanoostrum.org/ PGP key: [8DAE142BE17999C4]