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

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: larsi@gnus.org,  49066@debbugs.gnu.org,  mvsfrasson@gmail.com
> Date: Thu, 17 Jun 2021 15:07:18 +0200
> 
> Full backtrace from an unoptimized build:

Thanks.

>     >> 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));
> 
>     Eli> So, is 'g' a NULL pointer or something?  Or is 'lgstring' faulty in
>     Eli> some way?  IOW, what is the immediate reason for the
>     Eli> segfault?
> 
> Itʼs lgstring, I think this is one of those 'nil's in lgstring

Yes, I think so.  We can verify that by looking at the value of
g->g.to:

  (gdb) p *g
  $3 = {
    g = {
      c = 2453,
      code = 20,
      from = 0,
      to = 2, <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

And the LGLYPH whose index is 2 is indeed nil:

  (gdb) pp lgstring
  [[#<font-object "-GOOG-Noto Sans Bengali-normal-normal-normal-*-19-*-*-*-*-0-iso10646-1"> 2453 8204] nil [0 0 2453 20 16 -1 17 12 0 nil] [1 1 8204 658 0 -1 1 15 4 nil] nil nil nil [5 5 0 3039 11 0 12 7 5 nil] [6 6 1606 1044 11 0 11 8 3 nil] nil]  ^^^

I think this is a bug in that loop: it should actually exit whenever
it finds the first LGLYPH that is nil, and update gstring.used
accordingly.  Something like this:

  for (i = 0; i < gstring.used; i++)
    {
      MFLTGlyphFT *g = (MFLTGlyphFT *) (gstring.glyphs) + i;

      if (NILP (LGSTRING_GLYPH (lgstring, g->g.from))
          || NILP (LGSTRING_GLYPH (lgstring, g->g.to)))
	break;
      g->g.from = LGLYPH_FROM (LGSTRING_GLYPH (lgstring, g->g.from));
      g->g.to = LGLYPH_TO (LGSTRING_GLYPH (lgstring, g->g.to));
    }
  gstring.used = i;

CC'ing Handa-san, as I'm not really familiar with this code.

> This is enough to cause the crash: ক‌
> 
> Thats #x995 followed by #x200c. Why are we trying to compose a ZWNJ?

Because #x995 is a Bengali character, and lisp/language/indian.el
says:

  (defconst bengali-composable-pattern
    (let ((table
	   '(("a" . "\u0981")		; SIGN CANDRABINDU
	     ("A" . "[\u0982\u0983]")	; SIGN ANUSVARA .. VISARGA
	     ("V" . "[\u0985-\u0994\u09E0\u09E1]") ; independent vowel
	     ("C" . "[\u0995-\u09B9\u09DC-\u09DF\u09F1]") ; consonant
	     ("B" . "[\u09AC\u09AF\u09B0\u09F0]")		; BA, YA, RA
	     ("R" . "[\u09B0\u09F0]")		; RA
	     ("n" . "\u09BC")		; NUKTA
	     ("v" . "[\u09BE-\u09CC\u09D7\u09E2\u09E3]") ; vowel sign
	     ("H" . "\u09CD")		; HALANT
	     ("T" . "\u09CE")		; KHANDA TA
	     ("N" . "\u200C")		; ZWNJ  <<<<<<<<<<<<<<<<<<<<<<<<<<<
	     ("J" . "\u200D")		; ZWJ
	     ("X" . "[\u0980-\u09FF]"))))	; all coverage
      (indian-compose-regexp
       (concat
	;; syllables with an independent vowel, or
	"\\(?:RH\\)?Vn?\\(?:J?HB\\)?v*n?a?A?\\|"
	;; consonant-based syllables, or
	"Cn?\\(?:J?HJ?Cn?\\)*\\(?:H[NJ]?\\|v*[NJ]?v?a?A?\\)\\|"
	;; another syllables with an independent vowel, or
	"\\(?:RH\\)?T\\|"
	;; special consonant form, or
	"JHB\\|"
	;; any other singleton characters
	"X")
       table))
    "Regexp matching a composable sequence of Bengali characters.")

(which is used below that in setting up composition-function-table for
Bengali characters).

>     Eli> It could be some problem with the shaping engine: I guess versions
>     Eli> after Emacs 26 are built with HarfBuzz, not m17n-flt?  If you forcibly
>     Eli> use m17n-flt in a later Emacs, does it still not crash?
> 
> emacs-27 built '--without-harfbuzz' and thus with m17n-flt crashes the same way.

Yes, it figures.

I hope Handa-san will suggest a solution, for those who want to stick
with m17n-flt.