bug#38748: 28.0.50; crash on MacOS 10.15.2

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 38748@debbugs.gnu.org,  pipcet@gmail.com,  alan@idiocy.org,
>   jguenther@gmail.com,  andreyk.mad@gmail.com
> Date: Thu, 09 Jan 2020 11:31:25 +0100
> 
>     Eli> Also, can I please see one backtrace with all the call-stack frames,
>     Eli> starting from 'main' and ending at 'handle_fatal_signal'?  The
>     Eli> original report shows only the top-most 511 frames, and the other one
>     Eli> has a lot of ?? (missing symbols) in it.
> 
> 'bt full' backtrace attached.

Thanks.

> Thread 2 received signal SIGSEGV, Segmentation fault.
> 0x0000000100221f88 in vector_marked_p (v=0x20a000000000) at alloc.c:3726
> 3726    return XVECTOR_MARKED_P (v);
> (gdb) bt full
> #0  0x0000000100221f88 in vector_marked_p (v=0x20a000000000) at alloc.c:3726
> No locals.
> #1  0x00000001002255e5 in vectorlike_marked_p (header=0x20a000000000)
>     at alloc.c:3744
> No locals.
> #2  0x00000001002221c2 in mark_frame (ptr=0x164cc69a0) at alloc.c:6321
>         font = 0x20a000000000
>         f = 0x164cc69a0

This says that we were marking a frame, and its default font is a
garbled pointer.  Are all of the crashes you see happen because of a
faulty frame font in this snippet:

  static void
  mark_frame (struct Lisp_Vector *ptr)
  {
    struct frame *f = (struct frame *) ptr;
    mark_vectorlike (&ptr->header);
    mark_face_cache (f->face_cache);
  #ifdef HAVE_WINDOW_SYSTEM
    if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
      {
        struct font *font = FRAME_FONT (f);

        if (font && !vectorlike_marked_p (&font->header))  <<<<<<<<<<<<
          mark_vectorlike (&font->header);
      }
  #endif
  }

I hope you still have this crashed session in the debugger.  If so,
please tell: do you have many frames in that session, or just a few
(perhaps even one)?  I'd like to see some more details about this
frame, if possible.