[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0
From: |
Eli Zaretskii |
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@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.
- bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0,
Eli Zaretskii <=