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

[Thomas Fitzsimmons]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Darn, I forgot to increase GNU Screen's scrollback setting and that
information scrolled away.

> 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? 

Yes, I wondered that too.

> 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 other threads are all in __GI___poll.

> The information displayed by GDB when it catches a fatal signal tells
> that as well.

OK.

>> 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.

I will increase GNU Screen's scrollback and restart the run.  This will
probably happen again soonish, at which point I'll file the new bug
report with the signal information.

Thanks for analyzing the backtraces.

Thomas