GNU bug report logs - #77046
31.0.50; Emacs sometimes crashes

Previous Next

Full log

Message #44 received at 77046 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sat, 22 Mar 2025 12:20:16 +0000

"Markus Triska" <triska <at> metalevel.at> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Thanks.  I tried on GNU/Linux.
>
> I still get a crash also on Ubuntu 23.10, from which I also reported the
> original issue. I attach the new backtrace below.
>
>> I wonder what is it with your environment that produces unreproducible
>> results, even for such simple problems.  Note that the backtrace
>> you've shown indicated the crash was while loading some Lisp file,
>> which I don't understand at all.
>
> I try to keep every system I use as plain and simple as possible. To the
> best of my knowledge, this Ubuntu 23.10 is very close to a default
> installation, with a few additional packages installed.
>
> Please see below for the new backtrace, using:
>
>     $ ./emacs --version
>     GNU Emacs 31.0.50
>     Development version cf7fdd374ac9 on master branch; build date 2025-03-22.
>
> Thank you and all the best,
> Markus
>
> #0 0x000055555575e5a2 in internal_equal_1 (o1=0x7ffff47f2fac,
> o2=o2 <at> entry=0x555555a008e4, equal_kind=equal_kind <at> entry=EQUAL_PLAIN,
> depth=depth <at> entry=0, ht=ht <at> entry=0x7fffffffc4f8) at fns.c:2836

As Eli points out, this is very puzzling.  Can you disassemble
internal_equal_1 ("disass internal_equal_1") in the Emacs binary and
evaluate "p *(struct Lisp_String *)0x7ffff47f2fa8" and "p *(struct
Lisp_String *)0x555555a008e0" in a gdb session (either a live one or one
launched on the Emacs core dump)?

That should let us know why we fault at this strange source position.

> #1  0x000055555575f6a5 in internal_equal (ht=<optimized out>, depth=0, equal_kind=EQUAL_PLAIN, o2=0x555555a008e4, o1=<optimized out>) at fns.c:3000
> #2  Fequal (o2=0x555555a008e4, o1=<optimized out>) at fns.c:2795
> #3  Fassoc (key=0x555555a008e4, alist=0x7ffff47ec1bb, testfn=0x0) at fns.c:2025
> #4 0x0000555555796e2d in exec_byte_code (fun=<optimized out>,
> args_template=<optimized out>, nargs=<optimized out>, args=<optimized
> out>) at /emacs/src/lisp.h:2230
> #5  0x000055555574b42e in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffc680) at eval.c:3087

> #6 0x000055555566e969 in tty_lookup_color (f=f <at> entry=0x555555aeff60,
> color=0x555555a008e4, tty_color=tty_color <at> entry=0x7fffffffc720,
> std_color=std_color <at> entry=0x0) at xfaces.c:1090
> #7 0x0000555555675d8c in tty_defined_color (f=0x555555aeff60,
> color_name=0x555555ae1270 "unspecified-bg", color_def=0x7fffffffc720,
> alloc=<optimized out>, _makeIndex=<optimized out>) at xfaces.c:1153
> #8 0x000055555566e426 in load_color2 (f=0x555555aeff60,
> face=0x555555a6d370, name=0x555555a00634,
> target_index=LFACE_BACKGROUND_INDEX, color=0x7fffffffc720) at
> xfaces.c:1300

That line is:

  if (!FRAME_TERMINAL (f)->defined_color_hook
      (f, SSDATA (name), color, true, true))

which looks very unsafe to me: the SSDATA pointer will become invalid
when we compact strings, which we might do since tty_lookup_color calls
into Lisp.  The color_name pointer is used after that point in
tty_defined_color, possibly causing false negatives for the strcmp in
lines 1157/1159.

However, that doesn't really explain this crash, it's just another
(possibly latent) SDATA bug.  At first glance, there seem to be more of
hose in xfaces.c, though, so it's possible something further up the call
chain results in a corrupt SDATA pointer.

Pip

Previous Next

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