[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11003: Emacs-24 Hangs When Displaying Unicode #x6c0 (ARABIC HEH WITH
From: |
Eli Zaretskii |
Subject: |
bug#11003: Emacs-24 Hangs When Displaying Unicode #x6c0 (ARABIC HEH WITH YEH ABOVE) -- gdb backtrace |
Date: |
Tue, 13 Mar 2012 20:46:14 +0200 |
> 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.