bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pieter van Oostrum <pieter-l@vanoostrum.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
>> Cc: 39962@debbugs.gnu.org,  pieter@vanoostrum.org
>> Date: Sat, 07 Mar 2020 16:06:09 +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.

>> > 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.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]