From: Pieter van Oostrum <pieter-l@vanoostrum.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 39962@debbugs.gnu.org, eggert@cs.ucla.edu
Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 19:23:26 +0100 [thread overview]
Message-ID: <lx5zfcyspt.fsf@cochabamba.vanoostrum.org> (raw)
In-Reply-To: <83sgig9rg6.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Mar 2020 17:10:01 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 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]
next prev parent reply other threads:[~2020-03-10 18:23 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 23:55 bug#39962: 27.0.90; Crash in Emacs 27.0.90 Pieter van Oostrum
2020-03-07 7:48 ` Eli Zaretskii
2020-03-07 8:40 ` Pieter van Oostrum
2020-03-07 8:41 ` Pieter van Oostrum
2020-03-07 10:51 ` Eli Zaretskii
2020-03-07 11:06 ` Pieter van Oostrum
2020-03-07 13:10 ` Eli Zaretskii
2020-03-07 15:06 ` Pieter van Oostrum
2020-03-07 15:17 ` Eli Zaretskii
2020-03-07 15:49 ` Pieter van Oostrum
2020-03-07 16:07 ` Eli Zaretskii
2020-03-07 17:21 ` Pieter van Oostrum
2020-03-07 18:01 ` Eli Zaretskii
2020-03-07 19:14 ` Pieter van Oostrum
2020-03-07 19:21 ` Eli Zaretskii
2020-03-07 22:07 ` Pieter van Oostrum
2020-03-09 4:00 ` Pip Cet
2020-03-08 7:42 ` Paul Eggert
2020-03-08 9:34 ` Pieter van Oostrum
2020-03-08 10:05 ` Paul Eggert
2020-03-08 21:37 ` Pieter van Oostrum
2020-03-08 21:58 ` Pieter van Oostrum
2020-03-08 22:34 ` Paul Eggert
2020-03-08 23:58 ` Pieter van Oostrum
2020-03-09 0:01 ` Paul Eggert
2020-03-09 13:26 ` Pieter van Oostrum
2020-03-09 17:10 ` Eli Zaretskii
2020-03-09 19:48 ` Pieter van Oostrum
2020-03-10 13:37 ` Pieter van Oostrum
2020-03-09 19:51 ` Paul Eggert
2020-03-09 21:32 ` Pieter van Oostrum
2020-03-10 10:52 ` Pieter van Oostrum
2020-03-10 14:19 ` Pip Cet
2020-03-10 16:36 ` Pieter van Oostrum
2020-03-11 14:32 ` Pip Cet
2020-03-11 15:16 ` Pieter van Oostrum
2020-03-11 15:43 ` Pip Cet
2020-03-11 15:51 ` Paul Eggert
2020-03-11 16:21 ` Eli Zaretskii
2020-03-11 17:52 ` Eli Zaretskii
2020-03-11 18:53 ` Pip Cet
2020-03-11 19:34 ` Eli Zaretskii
2020-03-12 10:32 ` Pip Cet
2020-03-12 15:23 ` Eli Zaretskii
2020-03-12 20:36 ` Pip Cet
2020-03-13 9:39 ` Eli Zaretskii
2020-03-13 13:56 ` Pip Cet
2020-03-13 16:30 ` Eli Zaretskii
2020-03-14 9:02 ` Pip Cet
2020-03-14 15:39 ` Pip Cet
2020-03-14 16:00 ` Paul Eggert
2020-03-14 16:15 ` Pip Cet
2020-03-14 16:57 ` Eli Zaretskii
2020-03-14 18:34 ` Pip Cet
2020-03-14 19:09 ` Paul Eggert
2020-03-14 20:10 ` Eli Zaretskii
2020-03-15 12:12 ` Pip Cet
2020-03-15 14:53 ` Eli Zaretskii
2020-03-15 12:09 ` Pip Cet
2020-03-15 14:50 ` Eli Zaretskii
2020-03-16 16:31 ` Stefan Monnier
2020-03-11 20:03 ` Pieter van Oostrum
2020-03-12 13:55 ` Pip Cet
2020-03-12 18:13 ` Pieter van Oostrum
2020-03-12 20:00 ` Pip Cet
2020-03-13 8:09 ` Eli Zaretskii
2020-03-13 8:39 ` Pip Cet
2020-03-13 9:19 ` Eli Zaretskii
2020-03-13 17:43 ` Pieter van Oostrum
2020-03-14 3:38 ` Richard Stallman
2020-03-14 8:37 ` Eli Zaretskii
2020-03-14 9:16 ` Pip Cet
2020-03-14 15:34 ` Pip Cet
2020-03-13 17:42 ` Pieter van Oostrum
2020-03-13 19:34 ` Eli Zaretskii
2020-03-13 21:35 ` Pieter van Oostrum
2020-03-14 8:08 ` Eli Zaretskii
2020-03-14 21:32 ` Pieter van Oostrum
2020-03-15 19:49 ` Pieter van Oostrum
2020-03-15 19:57 ` Eli Zaretskii
2020-03-15 23:26 ` Pieter van Oostrum
2020-03-16 10:44 ` Pieter van Oostrum
2020-03-16 15:07 ` Eli Zaretskii
2020-03-16 15:33 ` Pip Cet
2020-03-16 17:19 ` Pip Cet
2020-03-17 3:29 ` Pieter van Oostrum
2020-03-17 4:54 ` Pip Cet
2020-03-17 5:20 ` Pip Cet
2020-03-17 8:45 ` Pieter van Oostrum
2020-03-17 13:54 ` Pip Cet
2020-03-17 15:27 ` Pieter van Oostrum
2020-03-17 20:16 ` Pip Cet
2020-03-17 23:32 ` Pieter van Oostrum
2020-03-18 15:05 ` Eli Zaretskii
2020-03-19 13:23 ` Pieter van Oostrum
2020-03-19 13:57 ` Pip Cet
2020-03-21 21:22 ` Pieter van Oostrum
2020-03-22 14:21 ` Eli Zaretskii
2020-03-22 15:48 ` Pip Cet
2020-03-23 19:34 ` Pip Cet
2020-03-17 8:40 ` Pieter van Oostrum
2020-03-17 15:33 ` Eli Zaretskii
2020-03-17 20:59 ` Paul Eggert
2020-03-18 6:17 ` Pip Cet
2020-03-18 9:22 ` Robert Pluim
2020-03-18 11:38 ` Pieter van Oostrum
2020-03-18 11:57 ` Paul Eggert
2020-03-18 14:08 ` Pip Cet
2020-03-19 19:17 ` Pieter van Oostrum
2020-03-19 19:31 ` Pip Cet
2020-03-19 21:30 ` Pieter van Oostrum
2020-03-18 14:08 ` Eli Zaretskii
2020-03-16 18:36 ` Pieter van Oostrum
2020-03-13 7:58 ` Eli Zaretskii
2020-03-10 15:10 ` Eli Zaretskii
2020-03-10 18:23 ` Pieter van Oostrum [this message]
2020-03-11 8:22 ` Paul Eggert
2022-04-30 12:38 ` Lars Ingebrigtsen
2022-05-29 13:19 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=lx5zfcyspt.fsf@cochabamba.vanoostrum.org \
--to=pieter-l@vanoostrum.org \
--cc=39962@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).