[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39962: 27.0.90; Crash in Emacs 27.0.90
From: |
Pieter van Oostrum |
Subject: |
bug#39962: 27.0.90; Crash in Emacs 27.0.90 |
Date: |
Tue, 10 Mar 2020 19:23:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (darwin) |
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]
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, (continued)
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/18
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Paul Eggert, 2020/03/18
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/18
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/19
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/19
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/19
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/18
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/16
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/10
- bug#39962: 27.0.90; Crash in Emacs 27.0.90,
Pieter van Oostrum <=
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Paul Eggert, 2020/03/11