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,  pieter@vanoostrum.org
> Date: Sat, 07 Mar 2020 16:49:46 +0100
> 
> >> (gdb) f 2
> >> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
> >>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
> >>     at insdel.c:294
> >> 294              eassert (m->bytepos >= m->charpos
> >> (gdb) p m
> >> $1 = (struct Lisp_Marker *) 0x1609db830
> >> (gdb) p m->bytepos
> >> $2 = 11538
> >> (gdb) p m->charpos
> >> $3 = 0
> >> (gdb) p Z_BYTE
> >> No symbol "Z_BYTE" in current context.
> >> (gdb) p Z
> >> No symbol "Z" in current context.
> >> (gdb) p current_buffer->text->z_byte
> >> No symbol "current_buffer" in current context.
> >> (gdb) p current_buffer
> >> No symbol "current_buffer" in current context.
> >> (gdb) p current_thread->m_current_buffer
> >> $4 = (struct buffer *) 0x15b29a4b0
> >> (gdb) p current_thread->m_current_buffer->text->z_byte
> >> $5 = 529784
> >> (gdb) p current_thread->m_current_buffer->text->z
> >> $6 = 529778
> >> (gdb)
> >
> > Thanks.  Could it be that the marker in question is from another
> > buffer?  How does m->buffer compare with
> > current_thread->m_current_buffer?
> 
> They are the same.

Wait a minute... how come m->charpos is zero?  That should never
happen, since buffer positions start from 1, and the value should be
close to m->bytepos anyway.

Can you show the full C backtrace?

> >> > Also note that this is no longer in GC, at least not directly.
> >> 
> >> That's right. Although the cause of this might also have caused the GC
> >> problem when the assertion would not have caught it.
> >
> > Are you saying that GC is somewhere up the call-stack?  If so, can
> > you show that?
> 
> No. What I meant is: if this is some kind of corruption of a data structure 
> and if it wouldn't have been caught by the assertion it might later have 
> caused problem in GC.

Anything's possible, but this is highly unlikely IME: GC is much more
sensitive to data corruption than anything else in Emacs.