bug#49066: 26.3; Segmentation fault on specific utf8 string

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  49066@debbugs.gnu.org,
>   mvsfrasson@gmail.com
> Date: Thu, 17 Jun 2021 09:43:03 +0200
> 
> This is from an optimized build of emacs-26.1. I can redo it with a
> '-g3 -O0' if you want.

That'd help.

> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> ftfont_shape_by_flt (matrix=<optimized out>, otf=<optimized out>, 
> ft_face=<optimized out>, font=<optimized out>, lgstring=...)
>     at ftfont.c:2573
> 2573        g->g.to = LGLYPH_TO (LGSTRING_GLYPH (lgstring, g->g.to));

So, is 'g' a NULL pointer or something?  Or is 'lgstring' faulty in
some way?  IOW, what is the immediate reason for the segfault?

> (gdb) bt
> #0  ftfont_shape_by_fltPython Exception <class 'gdb.error'> value has been 
> optimized out: 

What's the story with these Python exceptions?  Looks like some
problem in our .gdbinit?

>  (matrix=<optimized out>, otf=<optimized out>, ft_face=<optimized out>, 
> font=<optimized out>, lgstring=)
>     at ftfont.c:2573
> #1  ftfont_shapePython Exception <class 'gdb.error'> value has been optimized 
> out: 
>  (lgstring=, lgstring@entry=XIL(0xaa2755)) at ftfont.c:2615
> #2  0x00000000005d97f5 in xftfont_shape (lgstring=XIL(0xaa2755)) at 
> xftfont.c:670
> #3  0x000000000057fc2a in Ffont_shape_gstringPython Exception <class 
> 'gdb.error'> value has been optimized out: 
>  (gstring=) at font.c:4427
> #4  0x000000000056fede in funcall_subr (subr=0x97fac0 <Sfont_shape_gstring>, 
> numargs=numargs@entry=1, args=args@entry=0x7fffffff59a0)
>     at eval.c:2844
> #5  0x000000000056ecff in Ffuncall (nargs=<optimized out>, 
> args=args@entry=0x7fffffff5998) at lisp.h:600

The backtrace stops too soon.  Can you show more?  I'd like at the
very least to see which sequence of characters causes the trouble.
>From the above, I can only glean that we were performing a character
composition.

It could be some problem with the shaping engine: I guess versions
after Emacs 26 are built with HarfBuzz, not m17n-flt?  If you forcibly
use m17n-flt in a later Emacs, does it still not crash?

Thanks.