bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0

[Eli Zaretskii]

> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: 63711@debbugs.gnu.org
> Date: Wed, 31 May 2023 23:19:56 -0400
> 
> This Emacs run ultimately crashed tonight, but the signature seems
> different.

Crashed for what reason?  The information shown by GDB about the
signal which crashed Emacs is missing.

And the place in the source where it crashed looks strange:

  INLINE _GL_ATTRIBUTE_CONST bool
  pdumper_object_p (const void *obj)
  {
  #ifdef HAVE_PDUMPER
    uintptr_t obj_addr = (uintptr_t) obj;  <<<<<<<<<<<<<<<<<<<<<<<
    return dump_public.start <= obj_addr && obj_addr < dump_public.end;
  #else
    (void) obj;
    return false;
  #endif
  }

How can anything in this function crash?  The only possible reason I
can think of is C stack overflow (but the number of call-stack frames
is not large enough to justify that).  Or maybe another thread
crashed, not the main thread?  The information displayed by GDB when
it catches a fatal signal tells that as well.

> The GDB session is still running if you want me to check
> anything.  I wasn't doing anything special when this happened.  Does the
> backtrace suggest that garbage collection happened during a
> fontification operation?

Yes, this happened inside GC.  So it's most probably completely
unrelated to this bug, and so please submit a new bug report with all
the information.