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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 63711 <at> debbugs.gnu.org
Subject: bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0
Date: Thu, 01 Jun 2023 09:29:23 +0300

> From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
> Cc: 63711 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.