bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Mon, Mar 16, 2020 at 10:44 AM Pieter van Oostrum
<pieter-l@vanoostrum.org> wrote:
> Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
>
> >>> (gdb) p $rsp
> >>> $1 = (void *) 0x7ffeef9c9270
> >>
> >> What is the value of stack_bottom?
> >>
> > (gdb) p &stack_bottom_variable
> > $3 = (void **) 0x7ffeefbff628
> >
> > (gdb) p current_thread->m_stack_bottom
> > $4 = 0x7ffeefbff628 ""
> >
> >> And how many frames do you have in that backtrace, if you show all of
> >> it?
> >
> > 11567
> > #11567 0x00000001001c281e in main (argc=1, argv=0x7ffeefbff660) at 
> > emacs.c:2054
>
> (gdb) f 3
> #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
> }

Can you show the entire small vector block containing 0x12c488fc0?
Something like

x/1024gx 0x12c488000

should work.

What I think happened is that the vector free list got corrupted
somehow, and two vectors believed they owned the memory location
0x12c489040.

> So the end of the overlay = 0

It's nil, indeed. That does point to corruption.

> , and the size is negative. Corruption.

The size looks fine. It's a pseudovector, and tagged, so the two msbs
are 1, making it look negative.

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

It's very unlikely.