bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 12 Feb 2022 22:06:09 -0800
> From: "Greg A. Woods" <woods@robohack.ca>
> 
> First the ancient typo/bug:
> 
> fontset.el contains an errant definition for xlfd-regexp-spacing-subnum
> (with the value '8').  git-blame suggests this typo has lurked for 20
> years!
> 
> It should of course be '9':
> 
>     (defconst xlfd-regexp-spacing-subnum 9) ; fix a 20-year-old typo!

Thanks, fixed for the upcoming Emacs 28.  Fortunately, this defconst
were not used anywhere (which might explain how the typo survived for
so long).

> 	(font-families (cl-remove-duplicates
> 			(sort (font-family-list)
> 			      (lambda(x y) (string> (upcase x) (upcase y))))
> 			:test 'cl-equalp)))

This is not recommended as a way to get useful fonts.  My suggestion
is to use the following instead:

  (delete-dups
   (x-list-fonts "-*-*-medium-r-normal-*-*-*-*-*-*-iso10646-1"
		 'default (selected-frame)))

Indeed, using x-list-fonts indiscriminately could very well include
fonts that Emacs cannot use or even those which will crash Emacs.

> Finally a crash (working on reproducing it with GDB in the source tree,
> but my gdb is having trouble with the emacs .gdbinit):
> 
> Reading symbols from /usr/pkg/bin/emacs-26.1...
> [New process 12954]
> [New process 1873]
> Core was generated by `emacs'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007cdaa53676aa in _lwp_kill () from /usr/lib/libc.so.12
> [Current thread is 1 (process 12954)]
> (gdb) bt
> #0  0x00007cdaa53676aa in _lwp_kill () from /usr/lib/libc.so.12
> #1  0x00000000004dc6ac in terminate_due_to_signal (sig=sig@entry=11,
>     backtrace_limit=backtrace_limit@entry=40) at emacs.c:394
> #2  0x00000000004f2d13 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1769
> #3  0x00000000004f2f53 in deliver_thread_signal (sig=sig@entry=11,
>     handler=0x4f2d05 <handle_fatal_signal>) at sysdep.c:1743
> #4  0x00000000004f2fa6 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1781
> #5  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>)
>     at sysdep.c:1866
> #6  <signal handler called>
> #7  0x00000000005ad68d in fontset_find_font (fontset=fontset@entry=364, c=c@entry=180,
>     face=face@entry=0x7cdaad2db4c0, charset_id=charset_id@entry=-1,
>     fallback=fallback@entry=false) at fontset.c:550
> #8  0x00000000005adfd3 in fontset_font (fontset=fontset@entry=364, c=c@entry=180,
>     face=face@entry=0x7cdaad2db4c0, id=-1) at fontset.c:760
> #9  0x00000000005ae365 in face_for_char (f=0x7cdaafbf2c30,
>     face=face@entry=0x7cdaad2db4c0, c=180, pos=<optimized out>, object=<optimized out>)
>     at fontset.c:990
> #10 0x000000000043e186 in FACE_FOR_CHAR (object=<optimized out>, pos=<optimized out>,
>     character=<optimized out>, face=0x7cdaad2db4c0, f=<optimized out>)
>     at dispextern.h:1818
> #11 get_next_display_element (it=it@entry=0x7f7fffe82f90) at xdisp.c:7303
> #12 0x000000000044790b in display_line (it=it@entry=0x7f7fffe82f90,
>     cursor_vpos=cursor_vpos@entry=0) at xdisp.c:21409

Is this with the above Lisp program that tries all the fonts collected
by font-family-list, or is this with some other recipe to reproduce
the crash?  Also, was that in "emacs -Q"?