bug#11003: Emacs-24 Hangs When Displaying Unicode #x6c0 (ARABIC HEH WITH YEH ABOVE) -- gdb backtrace

[Eli Zaretskii <eliz@gnu.org>]

> From: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>
> Date: Mon, 12 Mar 2012 22:32:47 -0700
> 
> On emacs23, describe-char on that character produces:
> 
>     character: (1728, #o3300, #x6c0)
> preferred charset: unicode (Unicode (ISO10646))
>        code point: 0x06C0
>            syntax: w 	which means: word
>          category: .:Base, b:Arabic
>       buffer code: #xDB #x80
>         file code: #xDB #x80 (encoded by coding system utf-8-unix)
>           display: by this font (glyph code)
>     xft:-unknown-B Compset-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1 (#xC7)
> 
> Character code properties: customize what to show
>   name: ARABIC LETTER HEH WITH YEH ABOVE
>   old-name: ARABIC LETTER HAMZAH ON HA
>   general-category: Lo (Letter, Other)
>   decomposition: (1749 1620)

I see the same in the latest trunk of Emacs 24, FWIW.

> 0xb6b7de08 in OTF_drive_gdef () from /usr/lib/libotf.so.0
> (gdb) bt
> #0  0xb6b7de08 in OTF_drive_gdef () from /usr/lib/libotf.so.0
> #1  0x081fa512 in ftfont_drive_otf (font=0xbf9a5440, spec=0x8cf2fb8, in=0xbf9a5288, from=0, to=3, out=0xbf9a53c8, 
>     adjustment=0xbf9a4d30) at ftfont.c:1863
> #2  0xb6b649e5 in ?? () from /usr/lib/libm17n-flt.so.0
> #3  0xb6b67712 in ?? () from /usr/lib/libm17n-flt.so.0
> #4  0xb6b68820 in ?? () from /usr/lib/libm17n-flt.so.0
> #5  0xb6b6995e in mflt_run () from /usr/lib/libm17n-flt.so.0
> #6  0x081f9d49 in ftfont_shape_by_flt (matrix=0x9e0cb8c, otf=0x9f40fb8, ft_face=0x9e0be20, font=0x9e0cae0, 
>     lgstring=<optimized out>) at ftfont.c:2515
> #7  ftfont_shape (lgstring=138875853) at ftfont.c:2579
> #8  0x081fbde3 in xftfont_shape (lgstring=138875853) at xftfont.c:688
> #9  0x081ad064 in Ffont_shape_gstring (gstring=138875853) at font.c:4308
> #10 0x0819e0c0 in Ffuncall (nargs=2, args=0xbf9a5590) at eval.c:3002
> #11 0x081d4ad5 in exec_byte_code (bytestr=<optimized out>, vector=137272173, maxdepth=24, args_template=138756330, nargs=0, 
>     args=<optimized out>) at bytecode.c:785
> #12 0x0819db8f in funcall_lambda (fun=137272093, nargs=5, arg_vector=0xbf9a5888) at eval.c:3233
> #13 0x0819decb in Ffuncall (nargs=6, args=0xbf9a5884) at eval.c:3063
> #14 0x0819c8f6 in internal_condition_case_n (bfun=0x819dcf0 <Ffuncall>, nargs=6, args=0xbf9a5884, handlers=138756354, 
>     hfun=0x8076610 <safe_eval_handler>) at eval.c:1637
> #15 0x08074312 in safe_call (args=0xbf9a5884, nargs=6) at xdisp.c:2357
> #16 safe_call (nargs=6, args=0xbf9a5884) at xdisp.c:2341
> #17 0x081ee466 in autocmp_chars (rule=<optimized out>, charpos=<optimized out>, bytepos=15723, limit=<optimized out>, 
>     win=0xa25e6f8, face=0x9b96cd0, string=138756330) at composite.c:969
> #18 0x081f2b89 in composition_reseat_it (cmp_it=0xbf9a7110, charpos=14566, bytepos=15723, endpos=1, w=0xa25e6f8, 
>     face=0x9b96cd0, string=138756330) at composite.c:1300
> #19 0x080838c0 in next_element_from_buffer (it=0xbf9a6c40) at xdisp.c:7755

This is deep in the bowels of libotf and libm17n-flt.  Perhaps
Handa-san could look into this.