struct face question

struct face question

[Po Lu]

Is it ever valid for face->fontset to be -1?  The X font backend doesn't
support scaling fonts, so displaying the separator-line face fails to
find a font with height 0.1, causing the following part of
realize_gui_face to be called:

      else
	{
	  face->font = NULL;
	  face->fontset = -1;
	}

leading to face_for_char aborting from face->fontset being -1 later on.

Re: struct face question

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Fri, 16 Sep 2022 13:35:45 +0800
> 
> Is it ever valid for face->fontset to be -1?

Yes, I think so.  It means there's no fontset for this face.  Which is
normal when there's no font.

> The X font backend doesn't
> support scaling fonts, so displaying the separator-line face fails to
> find a font with height 0.1, causing the following part of
> realize_gui_face to be called:
> 
>       else
> 	{
> 	  face->font = NULL;
> 	  face->fontset = -1;
> 	}
> 
> leading to face_for_char aborting from face->fontset being -1 later on.

Please show a full backtrace from the crash, and preferably also a
reproducer.  What character are we trying to display in that case?

If indeed the X font backend doesn't support that, it would perhaps
call for a different definition of the face, but I'd like to
understand the issue better before we decide how to solve it.

Thanks.

Re: struct face question

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, I think so.  It means there's no fontset for this face.  Which is
> normal when there's no font.

Thanks.

>> The X font backend doesn't
>> support scaling fonts, so displaying the separator-line face fails to
>> find a font with height 0.1, causing the following part of
>> realize_gui_face to be called:
>> 
>>       else
>> 	{
>> 	  face->font = NULL;
>> 	  face->fontset = -1;
>> 	}
>> 
>> leading to face_for_char aborting from face->fontset being -1 later on.
>
> Please show a full backtrace from the crash, and preferably also a
> reproducer.  What character are we trying to display in that case?

In that specific case, a newline character.  But the problem can also be
easily reproduced with the following code:

  (insert (propertize "foo" 'face '(:height 0.1)))

as long as no core font of that height is installed.

Here is the backtrace from one such crash:

#0  terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:421
#1  0x000000000042df2a in die (msg=msg@entry=0x7181c0 "fontset_id_valid_p (face->fontset)", file=file@entry=0x717ebc "fontset.c", line=line@entry=925) at alloc.c:7672
#2  0x000000000043b697 in face_for_char (f=0x1a98c30 <bss_sbrk_buffer+13693584>, face=face@entry=0x9101e90, c=102, pos=1, object=XIL(0)) at fontset.c:925
#3  0x00000000004825a7 in FACE_FOR_CHAR (object=<optimized out>, pos=<optimized out>, character=<optimized out>, face=0x9101e90, f=<optimized out>) at /home/oldosfan/emacs-dev/emacs-gc/src/dispextern.h:1911
#4  get_next_display_element (it=0x7fffffff5c80) at xdisp.c:8244
#5  0x0000000000489140 in display_line (it=0x7fffffff5c80, cursor_vpos=<optimized out>) at xdisp.c:24726
#6  0x000000000048e903 in try_window (window=XIL(0x1a99c35), pos=..., flags=<optimized out>) at xdisp.c:20594
#7  0x00000000004afe08 in redisplay_window (window=<optimized out>, just_this_one_p=<optimized out>) at xdisp.c:19991
#8  0x00000000004b1a2b in redisplay_window_0 (window=window@entry=XIL(0x1a99c35)) at xdisp.c:17493
#9  0x0000000000611d64 in internal_condition_case_1 (bfun=bfun@entry=0x4b1a00 <redisplay_window_0>, arg=arg@entry=XIL(0x1a99c35), handlers=<optimized out>, hfun=hfun@entry=0x45df30 <redisplay_window_error>) at eval.c:1516
#10 0x000000000045c8e9 in redisplay_windows (window=XIL(0x1a99c35)) at xdisp.c:17463
#11 0x00000000004987eb in redisplay_internal () at xdisp.c:16912
#12 0x0000000000587821 in read_char (commandflag=1, map=XIL(0x9778b93), prev_event=XIL(0), used_mouse_menu=0x7fffffffd97b, end_time=0x0) at keyboard.c:2634
#13 0x000000000058b159 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10036
#14 0x000000000058d2ac in command_loop_1 () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:1163
#15 0x0000000000611cb7 in internal_condition_case (bfun=bfun@entry=0x58d090 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x57f9d0 <cmd_error>) at eval.c:1492
#16 0x0000000000575c7a in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1132
#17 0x0000000000611bf1 in internal_catch (tag=<optimized out>, func=func@entry=0x575c60 <command_loop_2>, arg=arg@entry=XIL(0x90)) at eval.c:1215
#18 0x0000000000576570 in command_loop () at keyboard.c:1110
#19 0x000000000057f19c in recursive_edit_1 () at keyboard.c:719
#20 0x000000000057f792 in Frecursive_edit () at keyboard.c:802
#21 0x000000000043dd6f in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2517

Re: struct face question

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 16 Sep 2022 15:31:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> leading to face_for_char aborting from face->fontset being -1 later on.
> >
> > Please show a full backtrace from the crash, and preferably also a
> > reproducer.  What character are we trying to display in that case?
> 
> In that specific case, a newline character.  But the problem can also be
> easily reproduced with the following code:
> 
>   (insert (propertize "foo" 'face '(:height 0.1)))
> 
> as long as no core font of that height is installed.

The assertion that triggers is too early: we don't use the fontset
information before this part:

  fontset = FONTSET_FROM_ID (face->fontset);
  eassert (!BASE_FONTSET_P (fontset));

So does the problem go away if you move the assertion before the first
of these two lines?

Re: struct face question

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The assertion that triggers is too early: we don't use the fontset
> information before this part:
>
>   fontset = FONTSET_FROM_ID (face->fontset);
>   eassert (!BASE_FONTSET_P (fontset));
>
> So does the problem go away if you move the assertion before the first
> of these two lines?

Yes it does.  Thanks, pushed.