bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pieter van Oostrum]

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]