GNU bug report logs -
#75725
SIGSEGV in emacs 30.0.93
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 08 Feb 2025 11:20:10 +0200
with message-id <86y0yg3i9h.fsf <at> gnu.org>
and subject line Re: bug#75725: SIGSEGV in emacs 30.0.93
has caused the debbugs.gnu.org bug report #75725,
regarding SIGSEGV in emacs 30.0.93
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
75725: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75725
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi,
I'm experiencing a segmentation violation in emacs 30.0.93 when linked against GTK.
The crash does not happen in the TUI version of emacs (which, obviously, is not
linked against GTK).
Backtrace:
#0 normal_char_ascent_descent (font=0x0, c=c <at> entry=-1, ascent=ascent <at> entry=0x7fffffff2ad0, descent=descent <at> entry=0x7fffffff2ad4)
at xdisp.c:30407
#1 0x000000000043b18b in normal_char_height (font=<optimized out>, c=c <at> entry=-1) at xdisp.c:30443
#2 0x0000000000455cdf in handle_single_display_spec (it=it <at> entry=0x7fffffff3150, spec=<optimized out>, spec <at> entry=0x28266e3,
object=<optimized out>, object <at> entry=0x28dc604, overlay=overlay <at> entry=0x0, position=position <at> entry=0x7fffffff32b8,
bufpos=bufpos <at> entry=0, display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:6114
#3 0x00000000004567de in handle_display_spec (it=it <at> entry=0x7fffffff3150, spec=<optimized out>, spec <at> entry=0x28266e3,
object=object <at> entry=0x28dc604, overlay=0x0, position=position <at> entry=0x7fffffff32b8, bufpos=bufpos <at> entry=0, frame_window_p=true)
at xdisp.c:5862
#4 0x0000000000456e95 in handle_display_prop (it=0x7fffffff3150) at xdisp.c:5770
#5 0x0000000000451357 in handle_stop (it=it <at> entry=0x7fffffff3150) at xdisp.c:4136
#6 0x0000000000452678 in next_element_from_string (it=0x7fffffff3150) at xdisp.c:9257
#7 0x00000000004585bc in get_next_display_element (it=it <at> entry=0x7fffffff3150) at xdisp.c:8210
#8 0x0000000000467458 in display_string (string=string <at> entry=0x0, lisp_string=lisp_string <at> entry=0x28dc604,
face_string=face_string <at> entry=0x0, face_string_pos=face_string_pos <at> entry=0, start=start <at> entry=0, it=it <at> entry=0x7fffffff3150,
field_width=<optimized out>, precision=<optimized out>, max_x=<optimized out>, multibyte=<optimized out>) at xdisp.c:29218
#9 0x0000000000467b62 in display_mode_element (it=it <at> entry=0x7fffffff3150, depth=6, depth <at> entry=5, field_width=0, precision=-79,
elt=0x28dc604, props=props <at> entry=0x0, risky=false) at xdisp.c:27755
#10 0x00000000004681b5 in display_mode_element (it=it <at> entry=0x7fffffff3150, depth=5, depth <at> entry=3, field_width=0, precision=-77,
elt=<optimized out>, props=props <at> entry=0x0, risky=false) at xdisp.c:28003
#11 0x00000000004681b5 in display_mode_element (it=it <at> entry=0x7fffffff3150, depth=3, depth <at> entry=1, field_width=-59, precision=-59,
elt=<optimized out>, props=props <at> entry=0x0, risky=false) at xdisp.c:28003
#12 0x00000000004681b5 in display_mode_element (it=it <at> entry=0x7fffffff3150, depth=1, depth <at> entry=0, field_width=field_width <at> entry=0,
precision=precision <at> entry=0, elt=<optimized out>, elt <at> entry=0x3cdb883, props=props <at> entry=0x0, risky=false) at xdisp.c:28003
#13 0x0000000000468ffe in display_mode_line (w=w <at> entry=0x1437d88, face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x3cdb883) at xdisp.c:27428
#14 0x000000000046aeac in display_mode_lines (w=w <at> entry=0x1437d88) at xdisp.c:27341
#15 0x000000000047b6c2 in redisplay_window (window=0x1437d8d, just_this_one_p=just_this_one_p <at> entry=false) at xdisp.c:20931
#16 0x000000000047d00f in redisplay_window_0 (window=window <at> entry=0x1437d8d) at xdisp.c:18020
#17 0x00000000005a5369 in internal_condition_case_1 (bfun=bfun <at> entry=0x47cfd8 <redisplay_window_0>, arg=0x1437d8d,
handlers=<optimized out>, hfun=hfun <at> entry=0x43ea8b <redisplay_window_error>) at eval.c:1637
#18 0x0000000000443646 in redisplay_windows (window=0x1437d8d) at xdisp.c:17989
#19 0x00000000004435ca in redisplay_windows (window=0xf41c935) at xdisp.c:17983
#20 0x000000000046c497 in redisplay_internal () at xdisp.c:17388
#21 0x000000000046cd2d in resize_echo_area_exactly () at xdisp.c:12909
#22 0x00000000005393a6 in command_loop_1 () at keyboard.c:1578
#23 0x00000000005a52e5 in internal_condition_case (bfun=bfun <at> entry=0x538bee <command_loop_1>, handlers=handlers <at> entry=0x90,
hfun=hfun <at> entry=0x52d63b <cmd_error>) at eval.c:1613
#24 0x00000000005275ee in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1168
#25 0x00000000005a5202 in internal_catch (tag=tag <at> entry=0x122d0, func=func <at> entry=0x5275d4 <command_loop_2>, arg=arg <at> entry=0x90)
at eval.c:1292
#26 0x00000000005275ab in command_loop () at keyboard.c:1146
#27 0x000000000052d194 in recursive_edit_1 () at keyboard.c:754
#28 0x000000000052d53c in Frecursive_edit () at keyboard.c:837
#29 0x00000000005269a0 in main (argc=<optimized out>, argv=0x7fffffff8588) at emacs.c:2635
The problem seems to be that xdisp.c:30407 invokes FONT_BASE on the font pointer
(which is a NULL pointer). I do not know why it would be NULL or if
normal_char_ascent_descent should check for NULL or if that should be caught
somewhere higher up in the call hierarchy. I can reproduce the behavior by
loading my previous session via doomemacs' doom-load-session but I do not have
a minimal test case that provokes this crash.
best regards
Florian
--
[Message part 3 (message/rfc822, inline)]
> Date: Wed, 22 Jan 2025 18:42:52 +0100
> From: Florian Franzmann <bwlf <at> bandrate.org>
> Cc: 75725 <at> debbugs.gnu.org
>
> On Mi 2025-01-22 16:34:49 +0200, Eli Zaretskii wrote:
> > > Date: Wed, 22 Jan 2025 08:06:42 +0100
> > > From: Florian Franzmann <bwlf <at> bandrate.org>
> > > Cc: 75725 <at> debbugs.gnu.org
> > >
> > > > > Maybe using MartianMono as doom-symbol-font is problematic?
> > > >
> > > > I don't know yet. Which characters is doom-symbol-font used for?
> > > >
> > > > But you could try that hypothesis by using some other font there, and
> > > > seeing if the previous build of Emacs still crashes then.
> > > >
> > > > Also, any idea which font is used on the mode line, and
> > > > what part of the mode line uses the '(raise FACTOR)' display property
> > > > there? That's the part where the display code hit the font = NULL
> > > > condition.
> > > In my modeline there is one character that for which there doesn't
> > > seem to be a glyph, unicode F418. gucharmap shows that one as a symbol
> > > for a version-control branch in MartianMono Nerd Font, I don't
> > > understand why emacs doesn't find the symbol, the rest of the modeline
> > > looks like it's using that font.
> >
> > U+F418 is a private-use character. Emacs knows nothing about such
> > characters, since their meaning is entirely up to the applications
> > and/or fonts that assigns the meaning to them. So if doom-emacs uses
> > such characters on the mode line, it must somehow arrange for that to
> > happen, since the "normal" font-selection machinery in Emacs doesn't
> > work for PUA characters.
> >
> > So I'm afraid I cannot be of much help here, as I don't know how
> > doom-emacs do this.
> That's fine, it works for me now. Thanks for the quick help!
No further comments, so I'm now closing this bug.
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.