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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 17 Jun 2021 11:13:17 +0300

> From: Robert Pluim <[email-masked]>
> Cc: Lars Ingebrigtsen <[email-masked]>,  [email-masked],
>   [email-masked]
> 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.