bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Eli Zaretskii]

> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
> Cc: 39962@debbugs.gnu.org,  eggert@cs.ucla.edu,  pipcet@gmail.com
> Date: Mon, 16 Mar 2020 11:44:40 +0100
> 
> #3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
> 6213        set_vectorlike_marked (&XMARKER (ptr->end)->header);
> (gdb) p *ptr
> $9 = {
>   header = {
>     size = -4611686018360274941
>   },
>   start = XIL(0x12c488fc5),
>   end = XIL(0),
>   plist = XIL(0x11dc4e263),
>   next = 0x12c488f30
> }
> 
> So the end of the overlay = 0, and the size is negative.

XIL(0) is not a position of zero, it's nil (which has binary
representation as zero).  IOW, the END marker of the overlay is nil,
something that shouldn't happen.  (The size prints negative because
the object is marked, and the mark bit makes it look like a negative
value.)  And thus this abort is different from the one you reported
originally: the failed assertion now says that something that should
have been a marker, isn't.

Is the START marker of that overlay valid (albeit marked)?  If so, is
its buffer live, i.e. is its name a Lisp string or is it nil?  And if
it's a live buffer, what kind of buffer is it?

> Corruption.  Maybe a stray assignment, or error in freeing memory.

It does look like memory corruption, although it's hard to imagine a
memory corruption that zeroes out one full 32-bit field of a struct,
but leaves the previous one and the next one intact.

> This build doesn't have the 
> 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch applied. I guess 
> that patch might help.

Didn't you say that an early version of that patch didn't help you
avoid the crashes?  But sure, go ahead and apply that patch, it cannot
possibly hurt.  Although the markers and the overlays are unlinked
from the buffer as part of kill-buffer, i.e. before that patch comes
into play...

An alternative idea is to write code that checks overlays for nil
markers, and then run this code periodically to find when such an
overlay appears.

Or maybe, given enough of such aborts, you could determine whether the
offending overlay always belongs to a certain buffer, and then we
could focus on monitoring that one buffer.

Thanks.