bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Eli Zaretskii]

> 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 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.