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

Previous Next

To reply to this bug, email your comments to 77046 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 10:55:35 +0100

Dear all,

while trying to reproduce #76186 with "-nw", I sometimes encounter a
crash. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76186#83, Eli
says this is worth a separate report, and so I am filing it here.

To try to reproduce the problem, please download the following file:

    https://www.metalevel.at/ei/recenter_sometimes_not_recentering_nw.el

and then launch Emacs with:

    $ emacs -Q -nw --load recenter_sometimes_not_recentering_nw.el

Leave it running for a while, and then press:

    C-g C-x C-c

Sometimes, but not always, this yields:

    /lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x7ad890e28150]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x7ad890e28209]
    emacs(+0x5bab5)[0x57deda682ab5]
    Segmentation fault (core dumped)

A backtrace produced by gdb after the crash is encountered follows.

I hope this helps also as a small step towards resolving #76186.

Thank you and all the best,
Markus


#0  0x000055555575c057 in plist_get (plist=<optimized out>, prop=0x7c20) at fns.c:2621
#1  0x000055555575c347 in Fget (propname=<optimized out>, symbol=<optimized out>) at fns.c:2641
#2  0x0000555555797aa0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:1207
#3  0x000055555574a98e in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffff35ff370) at eval.c:3069
#4  0x000055555574b002 in Fapply (nargs=2, args=0x7ffff35ff370) at eval.c:2698
#5  0x00005555557962bd in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#6  0x000055555574f284 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3191
#7  0x000055555574d872 in eval_sub (form=<optimized out>) at eval.c:2663
#8  0x000055555574f501 in Flet (args=<optimized out>) at eval.c:1076
#9  0x000055555574dc1f in eval_sub (form=<optimized out>) at eval.c:2525
#10 0x000055555574f720 in Fprogn (body=<optimized out>) at eval.c:439
#11 Flet (args=<optimized out>) at eval.c:1105
#12 0x000055555574dc1f in eval_sub (form=<optimized out>) at eval.c:2525
#13 0x000055555574ec78 in Fprogn (body=<optimized out>) at eval.c:439
#14 funcall_lambda (fun=fun <at> entry=0x555555a58bad, nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffd1e0) at eval.c:3326
#15 0x000055555574f284 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3191
#16 0x000055555574d872 in eval_sub (form=<optimized out>) at eval.c:2663
#17 0x000055555574e8f0 in Fprogn (body=<optimized out>) at eval.c:439
#18 prog_ignore (body=<optimized out>) at eval.c:450
#19 Fwhile (args=<optimized out>) at eval.c:1126
#20 0x000055555574dc1f in eval_sub (form=<optimized out>) at eval.c:2525
#21 0x000055555577762e in readevalloop_eager_expand_eval (val=<optimized out>, val <at> entry=0x7ffff735dff3, macroexpand=0xae30) at lread.c:2358
#22 0x000055555577efdc in readevalloop (readcharfun=readcharfun <at> entry=0x555555a585cd, infile0=infile0 <at> entry=0x0, sourcename=sourcename <at> entry=0x555555a60ae4, printflag=printflag <at> entry=false, unibyte=unibyte <at> entry=0x0, readfun=readfun <at> entry=0x0, start=0x0, end=<optimized out>) at lread.c:2540
#23 0x000055555578024e in Feval_buffer (buffer=<optimized out>, printflag=0x0, filename=0x555555a60ae4, unibyte=0x0, do_allow_print=<optimized out>) at lread.c:2618
#24 0x00005555557962bd in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#25 0x000055555574a98e in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0x7fffffffd7a0) at eval.c:3069
#26 0x000055555577fe41 in Fload (file=0x555555a59994, noerror=<optimized out>, nomessage=0x30, nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1615
#27 0x00005555557962bd in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#28 0x000055555574f284 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3191
#29 0x000055555574d872 in eval_sub (form=form <at> entry=0x7ffff49c1153) at eval.c:2663
#30 0x0000555555750083 in Feval (form=0x7ffff49c1153, lexical=<optimized out>) at eval.c:2438
#31 0x00005555557490d7 in internal_condition_case (bfun=bfun <at> entry=0x5555556b9720 <top_level_2>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556c1c30 <cmd_error>) at eval.c:1602
#32 0x00005555556ba25a in top_level_1 (ignore=ignore <at> entry=0x0) at keyboard.c:1191
#33 0x0000555555749019 in internal_catch (tag=tag <at> entry=0x11df0, func=func <at> entry=0x5555556ba230 <top_level_1>, arg=arg <at> entry=0x0) at eval.c:1282
#34 0x00005555556b967f in command_loop () at keyboard.c:1140
#35 0x00005555556c17a5 in recursive_edit_1 () at keyboard.c:749
#36 0x00005555556c1b44 in Frecursive_edit () at keyboard.c:832
#37 0x000055555559ebde in main (argc=<optimized out>, argv=0x7fffffffde28) at emacs.c:2560
quit



In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
 scroll bars) of 2025-03-16 built on laptop
Repository revision: db0bed7a68cd2308eba61247a6a77f73533ffef6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302000
System Description: Ubuntu 23.10

Configured using:
 'configure --with-gif=ifavailable --with-tiff=ifavailable
 --with-gnutls=ifavailable'

Configured features:
FREETYPE GMP JPEG LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP
SOUND THREADS TOOLKIT_SCROLL_BARS X11 XDBE XFT XIM XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: de_DE.UTF-8
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 13:04:46 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Date: Sun, 16 Mar 2025 10:55:35 +0100
> 
> Dear all,
> 
> while trying to reproduce #76186 with "-nw", I sometimes encounter a
> crash. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76186#83, Eli
> says this is worth a separate report, and so I am filing it here.
> 
> To try to reproduce the problem, please download the following file:
> 
>     https://www.metalevel.at/ei/recenter_sometimes_not_recentering_nw.el
> 
> and then launch Emacs with:
> 
>     $ emacs -Q -nw --load recenter_sometimes_not_recentering_nw.el
> 
> Leave it running for a while, and then press:
> 
>     C-g C-x C-c
> 
> Sometimes, but not always, this yields:
> 
>     /lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x7ad890e28150]
>     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x7ad890e28209]
>     emacs(+0x5bab5)[0x57deda682ab5]
>     Segmentation fault (core dumped)
> 
> A backtrace produced by gdb after the crash is encountered follows.

Thanks.  I see a very different backtrace, not sure why.  The problem
I see is fixed with the patch below.  Does it fix the problem for you?

Gerd, any comments for the patch?  I found that
combine_updates_for_frame was trying to combine updates for a
topmost_child frame whose after_make_frame flag was false and whose
desired_matrix was NULL.  That caused a segfault in
make_matrix_current, called from copy_child_glyphs, when make_current
dereferenced the pointer to desired_matrix.  AFAIU, we should not even
try redisplaying such frames.

diff --git a/src/xdisp.c b/src/xdisp.c
index ac65493..d7e0691 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -17569,7 +17569,10 @@ #define AINC(a,i)							\
 	  if (is_tty_frame (f))
 	    {
 	      /* Ignore all invisible tty frames, children or root.  */
-	      if (!frame_redisplay_p (f))
+	      if (!frame_redisplay_p (f)
+		  /* Ignore frames not yet completely made, which we
+		     cannot safely redisplay.  */
+		  || !f->after_make_frame)
 		continue;
 
 	      /* Remember tty root frames which we've seen.  */

> I hope this helps also as a small step towards resolving #76186.

I don't think this is related to the original problem in bug#76186.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77046 <at> debbugs.gnu.org, Markus Triska <triska <at> metalevel.at>
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 12:30:39 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Gerd, any comments for the patch?  I found that
> combine_updates_for_frame was trying to combine updates for a
> topmost_child frame whose after_make_frame flag was false and whose
> desired_matrix was NULL.  That caused a segfault in
> make_matrix_current, called from copy_child_glyphs, when make_current
> dereferenced the pointer to desired_matrix.  AFAIU, we should not even
> try redisplaying such frames.
>
> diff --git a/src/xdisp.c b/src/xdisp.c
> index ac65493..d7e0691 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -17569,7 +17569,10 @@ #define AINC(a,i)							\
>  	  if (is_tty_frame (f))
>  	    {
>  	      /* Ignore all invisible tty frames, children or root.  */
> -	      if (!frame_redisplay_p (f))
> +	      if (!frame_redisplay_p (f)
> +		  /* Ignore frames not yet completely made, which we
> +		     cannot safely redisplay.  */
> +		  || !f->after_make_frame)
>  		continue;
>  
>  	      /* Remember tty root frames which we've seen.  */
>

Yes, I think your patch is correct.

(I wonder a bit though, how redisplay got its hands on that child frame.
OTOH. the OP's .el with make-frame/delete-frame and redisplays in a
tight loop is something so unusual...)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 77046 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 13:37:30 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Markus Triska <triska <at> metalevel.at>,  77046 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 12:30:39 +0100
> 
> Yes, I think your patch is correct.

Thanks, installed on master.

> (I wonder a bit though, how redisplay got its hands on that child frame.
> OTOH. the OP's .el with make-frame/delete-frame and redisplays in a
> tight loop is something so unusual...)

Exactly my thoughts.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 12:43:15 +0100

Thank you all for looking into this and installing a correction!

Eli Zaretskii <eliz <at> gnu.org> writes:

>> (I wonder a bit though, how redisplay got its hands on that child frame.
>> OTOH. the OP's .el with make-frame/delete-frame and redisplays in a
>> tight loop is something so unusual...)
>
> Exactly my thoughts.

Tight loops I use in tests help to quickly exhibit issues that occur
only rarely. #76186 is another example of such an issue: It occurs very
rarely, and the tight loop helps to elicit it in a short time.

All the best,
Markus

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 13:50:07 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>   77046 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 12:43:15 +0100
> 
> Thank you all for looking into this and installing a correction!

Please tell if you still have crashes after the fix.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 16 Mar 2025 22:14:22 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Thank you all for looking into this and installing a correction!
>
> Please tell if you still have crashes after the fix.

Yes, I still get crashes also with the now current master branch:

    $ ./emacs --version
    GNU Emacs 31.0.50
    Development version eab14d68b2e7 on master branch; build date 2025-03-16.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Mon, 17 Mar 2025 14:33:23 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 22:14:22 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Thank you all for looking into this and installing a correction!
> >
> > Please tell if you still have crashes after the fix.
> 
> Yes, I still get crashes also with the now current master branch:
> 
>     $ ./emacs --version
>     GNU Emacs 31.0.50
>     Development version eab14d68b2e7 on master branch; build date 2025-03-16.

With the same backtrace which ends with

> #0  0x000055555575c057 in plist_get (plist=<optimized out>, prop=0x7c20) at fns.c:2621
> #1  0x000055555575c347 in Fget (propname=<optimized out>, symbol=<optimized out>) at fns.c:2641

?  Then I cannot reproduce this.  What is the probablity to get a
crash in your case using that recipe?  One in 3? one in 10? one in
100?

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Mon, 17 Mar 2025 19:08:39 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> With the same backtrace which ends with

The new crash is now on OSX, where I cannot easily run gdb and do not
see the backtrace. I will try again on the system from which I initially
reported this, when I can physically access it again next week.

> ?  Then I cannot reproduce this.  What is the probablity to get a
> crash in your case using that recipe?  One in 3? one in 10? one in
> 100?

My guess is around 1 in 10. I now got a crash again after 6 tries. It is
good to leave it running for a bit, and then interrupt it.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Mon, 17 Mar 2025 21:35:34 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Mon, 17 Mar 2025 19:08:39 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > With the same backtrace which ends with
> 
> The new crash is now on OSX, where I cannot easily run gdb and do not
> see the backtrace. I will try again on the system from which I initially
> reported this, when I can physically access it again next week.

Thanks.  I tried on GNU/Linux.

> > ?  Then I cannot reproduce this.  What is the probablity to get a
> > crash in your case using that recipe?  One in 3? one in 10? one in
> > 100?
> 
> My guess is around 1 in 10. I now got a crash again after 6 tries. It is
> good to leave it running for a bit, and then interrupt it.

I leave it to run to frame numbers in hundreds or thousands before I
interrupt the command.  It never crashes, definitely not 1 in 10.

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.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sat, 22 Mar 2025 09:00:27 +0100

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
#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
#9  0x000055555566eafe in load_color (target_index=LFACE_BACKGROUND_INDEX, name=0x555555a00634, face=0x555555a6d370, f=0x555555aeff60) at xfaces.c:1363
#10 map_tty_color (f=f <at> entry=0x555555aeff60, face=face <at> entry=0x555555a6d370, color=0x555555a00634, idx=idx <at> entry=LFACE_BACKGROUND_INDEX, defaulted=<optimized out>) at xfaces.c:6575
#11 0x00005555556765a5 in realize_tty_face (cache=0x555555a667e0, attrs=0x7fffffffc810) at xfaces.c:6725
#12 realize_face (cache=cache <at> entry=0x555555a667e0, attrs=attrs <at> entry=0x7fffffffc810, former_face_id=former_face_id <at> entry=16) at xfaces.c:6127
#13 0x0000555555677ea8 in realize_named_face (f=f <at> entry=0x555555aeff60, symbol=symbol <at> entry=0xac80, id=id <at> entry=16) at xfaces.c:6095
#14 0x000055555567828a in realize_basic_faces (f=f <at> entry=0x555555aeff60) at xfaces.c:5902
#15 0x000055555567892d in init_frame_faces (f=f <at> entry=0x555555aeff60) at xfaces.c:687
#16 0x00005555555b5478 in Fmake_terminal_frame (parms=<optimized out>) at frame.c:1682
#17 0x0000555555796e2d in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#18 0x000055555574b42e in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7ffff35ff370) at eval.c:3087
#19 0x000055555574baa2 in Fapply (nargs=2, args=0x7ffff35ff370) at eval.c:2716
#20 0x0000555555796e2d in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#21 0x000055555574fde4 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3209
#22 0x000055555574e3d2 in eval_sub (form=<optimized out>) at eval.c:2681
#23 0x0000555555750061 in Flet (args=<optimized out>) at eval.c:1094
#24 0x000055555574e77f in eval_sub (form=<optimized out>) at eval.c:2543
#25 0x0000555555750280 in Fprogn (body=<optimized out>) at eval.c:439
#26 Flet (args=<optimized out>) at eval.c:1123
#27 0x000055555574e77f in eval_sub (form=<optimized out>) at eval.c:2543
#28 0x000055555574f7d8 in Fprogn (body=<optimized out>) at eval.c:439
#29 funcall_lambda (fun=fun <at> entry=0x555555a5b7ed, nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffd1f0) at eval.c:3344
#30 0x000055555574fde4 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3209
#31 0x000055555574e3d2 in eval_sub (form=<optimized out>) at eval.c:2681
#32 0x000055555574f450 in Fprogn (body=<optimized out>) at eval.c:439
#33 prog_ignore (body=<optimized out>) at eval.c:450
#34 Fwhile (args=<optimized out>) at eval.c:1144
#35 0x000055555574e77f in eval_sub (form=<optimized out>) at eval.c:2543
#36 0x000055555577819e in readevalloop_eager_expand_eval (val=<optimized out>, val <at> entry=0x7ffff739e1c3, macroexpand=0xae30) at lread.c:2358
#37 0x000055555577fb4c in readevalloop (readcharfun=readcharfun <at> entry=0x555555a5b20d, infile0=infile0 <at> entry=0x0, sourcename=sourcename <at> entry=0x555555a57d24, printflag=printflag <at> entry=false, unibyte=unibyte <at> entry=0x0, readfun=readfun <at> entry=0x0, start=0x0, end=<optimized out>) at lread.c:2540
#38 0x0000555555780dbe in Feval_buffer (buffer=<optimized out>, printflag=0x0, filename=0x555555a57d24, unibyte=0x0, do_allow_print=<optimized out>) at lread.c:2618
#39 0x0000555555796e2d in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#40 0x000055555574b42e in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0x7fffffffd7b0) at eval.c:3087
#41 0x00005555557809b1 in Fload (file=0x555555a57a64, noerror=<optimized out>, nomessage=0x30, nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1615
#42 0x0000555555796e2d in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /emacs/src/lisp.h:2230
#43 0x000055555574fde4 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count <at> entry=...) at eval.c:3209
#44 0x000055555574e3d2 in eval_sub (form=form <at> entry=0x7ffff49c14eb) at eval.c:2681
#45 0x0000555555750be3 in Feval (form=0x7ffff49c14eb, lexical=<optimized out>) at eval.c:2456
#46 0x0000555555749b77 in internal_condition_case (bfun=bfun <at> entry=0x5555556b9e10 <top_level_2>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556c2630 <cmd_error>) at eval.c:1620
#47 0x00005555556ba94a in top_level_1 (ignore=ignore <at> entry=0x0) at keyboard.c:1191
#48 0x0000555555749ab9 in internal_catch (tag=tag <at> entry=0x11df0, func=func <at> entry=0x5555556ba920 <top_level_1>, arg=arg <at> entry=0x0) at eval.c:1300
#49 0x00005555556b9d6f in command_loop () at keyboard.c:1140
#50 0x00005555556c21a5 in recursive_edit_1 () at keyboard.c:749
#51 0x00005555556c2544 in Frecursive_edit () at keyboard.c:832
#52 0x000055555559ec1e in main (argc=<optimized out>, argv=0x7fffffffde38) at emacs.c:2560

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sat, 22 Mar 2025 13:04:55 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 09:00:27 +0100
> 
> 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

Line 2836 of fns.c is this:

  static bool
  internal_equal_1 (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind,
		    int depth, Lisp_Object *ht)
  { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
   tail_recurse:
    if (depth > 10)

So the only way I can understand how that line could trigger a crash
is that you have C stack overflow, something that is hard to believe
with just 55 call-stack frames in the backtrace.  IOW, it's a mystery
how and why does this crash in your case.

Maybe Gerd could have some ideas.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77046 <at> debbugs.gnu.org, Markus Triska <triska <at> metalevel.at>
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sat, 22 Mar 2025 13:04:58 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Markus Triska <triska <at> metalevel.at>
>> Cc: gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
>> Date: Sat, 22 Mar 2025 09:00:27 +0100
>> 
>> 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
>
> Line 2836 of fns.c is this:
>
>   static bool
>   internal_equal_1 (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind,
> 		    int depth, Lisp_Object *ht)
>   { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>    tail_recurse:
>     if (depth > 10)
>
> So the only way I can understand how that line could trigger a crash
> is that you have C stack overflow, something that is hard to believe
> with just 55 call-stack frames in the backtrace.  IOW, it's a mystery
> how and why does this crash in your case.
>
> Maybe Gerd could have some ideas.

Not really, I'm afraid, except to build Emacs with debug, configure with
--enable-checking=yes,glyphs and try to get it reproduced.

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

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

From: Markus Triska <triska <at> metalevel.at>
To: Pip Cet <pipcet <at> protonmail.com>
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 15:07:55 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

> 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

Regarding the strange positions, I think I found out what is causing
this: When I press C-g C-x C-c in the example I posted, then GDB
apparently already becomes active after C-g! I previously did not notice
it because I thought I had input the entire key sequence and expected
GDB to become active in this way only after a crash.

If possible, could you please recommend a way to run the example so that
GDB only becomes active when a crash is encountered?

Also, I have now recompiled Emacs as advised for debugging (i.e., with
--enable-checking='yes,glyphs' --enable-check-lisp-object-type \
CFLAGS='-O0 -g3').

The output I see on the shell (without GDB) for the example follows.

All the best,
Markus

$ ./emacs -nw -Q --load recenter_sometimes_not_recentering_nw.el
Fatal error 11: Segmentation fault
Backtrace:
./emacs(+0x23fcf8)[0x568e3c9fdcf8]
./emacs(+0x20547a)[0x568e3c9c347a]
./emacs(+0x23f42b)[0x568e3c9fd42b]
./emacs(+0x23f3fc)[0x568e3c9fd3fc]
./emacs(+0x23f474)[0x568e3c9fd474]
./emacs(+0x23f624)[0x568e3c9fd624]
/lib/x86_64-linux-gnu/libc.so.6(+0x42990)[0x7add5de42990]
./emacs(+0x49e87)[0x568e3c807e87]
./emacs(+0x49eb9)[0x568e3c807eb9]
./emacs(+0x4a719)[0x568e3c808719]
./emacs(+0x4b5ba)[0x568e3c8095ba]
./emacs(+0x4b944)[0x568e3c809944]
./emacs(+0xae1e4)[0x568e3c86c1e4]
./emacs(+0xab87d)[0x568e3c86987d]
./emacs(+0x2128ec)[0x568e3c9d08ec]
./emacs(+0x227abf)[0x568e3c9e5abf]
./emacs(+0x20e8c8)[0x568e3c9cc8c8]
./emacs(+0x2f6bfd)[0x568e3cab4bfd]
./emacs(+0x20e01d)[0x568e3c9cc01d]
./emacs(+0x2f5fce)[0x568e3cab3fce]
./emacs(+0x20dfab)[0x568e3c9cbfab]
./emacs(+0x20d2ef)[0x568e3c9cb2ef]
./emacs(+0x20d523)[0x568e3c9cb523]
./emacs(+0x208a31)[0x568e3c9c6a31]
/lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x7add5de28150]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x7add5de28209]
./emacs(+0x3f5c5)[0x568e3c7fd5c5]

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

From: Markus Triska <triska <at> metalevel.at>
To: Pip Cet <pipcet <at> protonmail.com>
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 15:19:09 +0100

I found it, please see below, does this help?

All the best,
Markus

Program received signal SIGSEGV, Segmentation fault.
0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
3499	  for (int i = 0; i < matrix->nrows; ++i)
#0  0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
#1  0x000055555559deb9 in make_matrix_current (f=0x555555c57ae8) at dispnew.c:3511
#2  0x000055555559e719 in copy_child_glyphs (root=0x555555b15660, child=0x555555c57ae8) at dispnew.c:3715
#3  0x000055555559f5ba in combine_updates_for_frame (f=0x555555b15660, inhibit_scrolling=false) at dispnew.c:4020
#4  0x000055555559f944 in combine_updates (roots=XIL(0x7ffff7345eb3)) at dispnew.c:4073
#5  0x00005555556021e4 in redisplay_internal () at xdisp.c:17748
#6  0x00005555555ff87d in redisplay () at xdisp.c:16802
#7  0x00005555557668ec in read_char (commandflag=1, map=XIL(0x7ffff73463e3), prev_event=XIL(0), used_mouse_menu=0x7fffffffd739, end_time=0x0) at keyboard.c:2672
#8  0x000055555577babf in read_key_sequence (keybuf=0x7fffffffd960, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at keyboard.c:10848
#9  0x00005555557628c8 in command_loop_1 () at keyboard.c:1424
#10 0x000055555584abfd in internal_condition_case (bfun=0x55555576247a <command_loop_1>, handlers=XIL(0x90), hfun=0x55555576186d <cmd_error>) at eval.c:1620
#11 0x000055555576201d in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1163
#12 0x0000555555849fce in internal_catch (tag=XIL(0x11df0), func=0x555555761fef <command_loop_2>, arg=XIL(0x90)) at eval.c:1300
#13 0x0000555555761fab in command_loop () at keyboard.c:1141
#14 0x00005555557612ef in recursive_edit_1 () at keyboard.c:749
#15 0x0000555555761523 in Frecursive_edit () at keyboard.c:832
#16 0x000055555575ca31 in main (argc=5, argv=0x7fffffffde28) at emacs.c:2560

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

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

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

> From: Markus Triska <triska <at> metalevel.at>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 15:07:55 +0100
> 
> Pip Cet <pipcet <at> protonmail.com> writes:
> 
> > 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
> 
> Regarding the strange positions, I think I found out what is causing
> this: When I press C-g C-x C-c in the example I posted, then GDB
> apparently already becomes active after C-g! I previously did not notice
> it because I thought I had input the entire key sequence and expected
> GDB to become active in this way only after a crash.
> 
> If possible, could you please recommend a way to run the example so that
> GDB only becomes active when a crash is encountered?

Yes, say

  (gdb) source /path/to/emacs/src/.gdbinit

before starting Emacs under GDB.  On TTY frames, Emacs programs the
terminal to generate SIGINT when the user presses C-g, so Emacs gets
delivered SIGINT and GDB kicks in.  The file src/.gdbinit in the Emacs
source tree causes GDB to pass SIGINT to Emacs without stopping it.

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

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

> From: Markus Triska <triska <at> metalevel.at>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 15:19:09 +0100
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
> 3499	  for (int i = 0; i < matrix->nrows; ++i)
> #0  0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
> #1  0x000055555559deb9 in make_matrix_current (f=0x555555c57ae8) at dispnew.c:3511
> #2  0x000055555559e719 in copy_child_glyphs (root=0x555555b15660, child=0x555555c57ae8) at dispnew.c:3715
> #3  0x000055555559f5ba in combine_updates_for_frame (f=0x555555b15660, inhibit_scrolling=false) at dispnew.c:4020
> #4  0x000055555559f944 in combine_updates (roots=XIL(0x7ffff7345eb3)) at dispnew.c:4073
> #5  0x00005555556021e4 in redisplay_internal () at xdisp.c:17748

That's exactly the crash that I fixed with commit 412a6fad98e7 a week
ago, after which I could no longer reproduce the problem.  So either
your source tree is out of sync with the master branch, or some other
factor is at work here.  Or maybe this backtrace is from Emacs before
my fix?

What does the below produce in GDB?

  (gdb) frame 1
  (gdb) print f->after_make_frame

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

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

> Date: Sat, 22 Mar 2025 12:20:16 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
> 
> > #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.

Does the below look OK?  I think it solves several SSDATA issues,
since tty_defined_color is called from several other places that pass
it SSDATA of some Lisp string.  But if you see some other place where
similar problems could happen and are not solved by the patch below,
please point them out.

diff --git a/src/xfaces.c b/src/xfaces.c
index fbbaffb..7a4571c 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -1150,14 +1150,18 @@ tty_defined_color (struct frame *f, const char *color_name,
   color_def->green = 0;
 
   if (*color_name)
-    status = tty_lookup_color (f, build_string (color_name), color_def, NULL);
-
-  if (color_def->pixel == FACE_TTY_DEFAULT_COLOR && *color_name)
     {
-      if (strcmp (color_name, "unspecified-fg") == 0)
-	color_def->pixel = FACE_TTY_DEFAULT_FG_COLOR;
-      else if (strcmp (color_name, "unspecified-bg") == 0)
-	color_def->pixel = FACE_TTY_DEFAULT_BG_COLOR;
+      Lisp_Object lcolor = build_string (color_name);
+      status = tty_lookup_color (f, lcolor, color_def, NULL);
+
+      if (color_def->pixel == FACE_TTY_DEFAULT_COLOR)
+	{
+	  color_name = SSDATA (lcolor);
+	  if (strcmp (color_name, "unspecified-fg") == 0)
+	    color_def->pixel = FACE_TTY_DEFAULT_FG_COLOR;
+	  else if (strcmp (color_name, "unspecified-bg") == 0)
+	    color_def->pixel = FACE_TTY_DEFAULT_BG_COLOR;
+	}
     }
 
   if (color_def->pixel != FACE_TTY_DEFAULT_COLOR)

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

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

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Sat, 22 Mar 2025 12:20:16 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
>>
>> > #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.
>
> Does the below look OK?  I think it solves several SSDATA issues,

It does, yes!  I thought there were more issues, but that was apparently
a mistake of mine.  Sorry about that.

Pip

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

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

> Date: Sat, 22 Mar 2025 16:25:01 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: triska <at> metalevel.at, gerd.moellmann <at> gmail.com, 77046 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> >> 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.
> >
> > Does the below look OK?  I think it solves several SSDATA issues,
> 
> It does, yes!  I thought there were more issues, but that was apparently
> a mistake of mine.  Sorry about that.

Thanks, installed on master.

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:

> your source tree is out of sync with the master branch, or some other
> factor is at work here.  Or maybe this backtrace is from Emacs before
> my fix?

In the example I posted, the crash still occurs also with a freshly
compiled Emacs from today's master branch which includes your fix.

>
> What does the below produce in GDB?
>
>   (gdb) frame 1
>   (gdb) print f->after_make_frame

I get:

    Program received signal SIGSEGV, Segmentation fault.
                                                        0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
    3499      for (int i = 0; i < matrix->nrows; ++i)
    (gdb) frame 1
    #1  0x000055555559deb9 in make_matrix_current (f=0x555555b9b520)
        at dispnew.c:3511
    3511      int first_row = first_enabled_row (f->desired_matrix);
    (gdb) print f->after_make_frame
    $1 = false

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

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

> From: Markus Triska <triska <at> metalevel.at>
> Cc: pipcet <at> protonmail.com,  gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 19:08:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > your source tree is out of sync with the master branch, or some other
> > factor is at work here.  Or maybe this backtrace is from Emacs before
> > my fix?
> 
> In the example I posted, the crash still occurs also with a freshly
> compiled Emacs from today's master branch which includes your fix.
> 
> >
> > What does the below produce in GDB?
> >
> >   (gdb) frame 1
> >   (gdb) print f->after_make_frame
> 
> I get:
> 
>     Program received signal SIGSEGV, Segmentation fault.
>                                                         0x000055555559de87 in first_enabled_row (matrix=0x0) at dispnew.c:3499
>     3499      for (int i = 0; i < matrix->nrows; ++i)
>     (gdb) frame 1
>     #1  0x000055555559deb9 in make_matrix_current (f=0x555555b9b520)
>         at dispnew.c:3511
>     3511      int first_row = first_enabled_row (f->desired_matrix);
>     (gdb) print f->after_make_frame
>     $1 = false

Thanks.  I don't understand how's that possible, but I installed a
couple of trivial band-aids.

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks.  I don't understand how's that possible, but I installed a
> couple of trivial band-aids.

Thank you! With 893c40c63e8e, the crashes still occur.

The current situation has the nice advantage that I can quite easily
reproduce the crash, adding new changes may also require changes in the
example which may also lead to a more complex and harder to reproduce
test case.

A second issue now present is the question why the crash can only be
reproduced in some but not all configurations.

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

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

> From: Markus Triska <triska <at> metalevel.at>
> Cc: pipcet <at> protonmail.com,  gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 20:58:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks.  I don't understand how's that possible, but I installed a
> > couple of trivial band-aids.
> 
> Thank you! With 893c40c63e8e, the crashes still occur.

I give up.  Let someone smarter solve this.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 77046 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sat, 22 Mar 2025 18:25:46 -0400

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

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Thanks.  I don't understand how's that possible, but I installed a
>> couple of trivial band-aids.
>
> Thank you! With 893c40c63e8e, the crashes still occur.
>
> The current situation has the nice advantage that I can quite easily
> reproduce the crash, adding new changes may also require changes in the
> example which may also lead to a more complex and harder to reproduce
> test case.
>
> A second issue now present is the question why the crash can only be
> reproduced in some but not all configurations.

If you can repro the crash, you can run it under rr and then just
reverse-execute the program to see what went wrong.  It's super
effective for dealing with problems like this.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: triska <at> metalevel.at
Cc: gerd.moellmann <at> gmail.com, pipcet <at> protonmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 23 Mar 2025 07:46:59 +0200

> Cc: gerd.moellmann <at> gmail.com, pipcet <at> protonmail.com, 77046 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 22:22:23 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Markus Triska <triska <at> metalevel.at>
> > Cc: pipcet <at> protonmail.com,  gerd.moellmann <at> gmail.com,  77046 <at> debbugs.gnu.org
> > Date: Sat, 22 Mar 2025 20:58:11 +0100
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > Thanks.  I don't understand how's that possible, but I installed a
> > > couple of trivial band-aids.
> > 
> > Thank you! With 893c40c63e8e, the crashes still occur.
> 
> I give up.  Let someone smarter solve this.

Too soon: it turns out the change I pushed was rejected, so now pushed
again.  Please try with the latest master.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, pipcet <at> protonmail.com, 77046 <at> debbugs.gnu.org
Subject: Re: bug#77046: 31.0.50; Emacs sometimes crashes
Date: Sun, 23 Mar 2025 09:12:55 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Too soon: it turns out the change I pushed was rejected, so now pushed
> again.  Please try with the latest master.

I no longer encounter the crash with the latest master version, thank
you a lot!

Regarding your commit message: This is the first and simplest test case
I created using frames on TTY, and it led to 3 distinct fixes that are
now applied. Without these fixes, we will run into situations that cause
such crashes. The loop I used helps to elicit such scenarios.

Thank you and all the best,
Markus

Previous Next

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