GNU bug report logs - #16457
24.3.50; crash rendering Arabic Uthmani script

Previous Next

Full log

Message #32 received at 16457 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16457 <at> debbugs.gnu.org
Subject: Re: bug#16457: 24.3.50; crash rendering Arabic Uthmani script
Date: Fri, 17 Jan 2014 15:16:56 +0400

[Message part 1 (text/plain, inline)]

On 01/17/2014 01:10 PM, Eli Zaretskii wrote:

> Can you show the same results of debugging printouts in a
> "--without-m17n-flt" build?

Results are eventually empty - I don't see anything. IOW, composition_update_it
is never called, at least when I do (move-to-column 10). Since this doesn't crash,
I can do M-x describe-char at column 10, which is:

             position: 17 of 100 (16%), column: 10
            character: ّ (displayed as ّ) (codepoint 1617, #o3121, #x651)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x0651
               script: arabic
               syntax: w 	which means: word
             category: b:Arabic
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #xD9 #x91
            file code: #xD9 #x91 (encoded by coding system utf-8-unix)
              display: by this font (glyph code)
    xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 (#x47C)

Character code properties: customize what to show
  name: ARABIC SHADDA
  old-name: ARABIC SHADDAH
  general-category: Mn (Mark, Nonspacing)
  decomposition: (1617) ('ّ')

> So what does that mean? that cmp_it->nchars here
>
>        cmp_it->nchars = LGLYPH_TO (glyph) + 1 - from;
>
> is incorrect in your case?  Or that the gstring header becomes
> corrupted somehow?

No ideas - this needs more tracing.

> Can you show the gstring header at that point in the build that
> crashes?

Note that original gstring header is copied in composition_gstring_put_cache,
so it's better to print both:

@@ -675,9 +676,13 @@
     }

   copy = Fmake_vector (make_number (len + 2), Qnil);
+  fprintf (stderr, "%s: original header %p is: ", __func__, XPNTR (header));
+  debug_print (header);
   LGSTRING_SET_HEADER (copy, Fcopy_sequence (header));
   for (i = 0; i < len; i++)
     LGSTRING_SET_GLYPH (copy, i, Fcopy_sequence (LGSTRING_GLYPH (gstring, i)));
+  fprintf (stderr, "%s: copy %p is: ", __func__, XPNTR (LGSTRING_HEADER (copy)));
+  debug_print (LGSTRING_HEADER (copy));
   i = hash_put (h, LGSTRING_HEADER (copy), copy, hash);
   LGSTRING_SET_ID (copy, make_number (i));
   return copy;

Result is attached. For the moment, I assume that gstring header is valid,
but some values within cmp_it (in composition_update_it at least) aren't.

> Also, if you manually move point to buffer position 11, what column
> number do you see there?

I can't move to 11 by advancing the cursor because it crasher earlier.

BTW, there is one more glitch - when I do 'emacs -Q uthmani-test.txt',
then 'M-x column-number-mode', then [left-arrow] few times, the column
number in mode line becomes incorrect and shown as 1003 or something
like this.

Dmitry

[bug16457_debug.log.gz (application/gzip, attachment)]

[bug16457_column_number.png (image/png, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.