From: Dmitry Antipov <dmantipov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 16457@debbugs.gnu.org
Subject: bug#16457: 24.3.50; crash rendering Arabic Uthmani script
Date: Fri, 17 Jan 2014 11:34:11 +0400 [thread overview]
Message-ID: <52D8DCF3.5030603@yandex.ru> (raw)
In-Reply-To: <83a9ev3k7x.fsf@gnu.org>
On 01/16/2014 09:33 PM, Eli Zaretskii wrote:
> This is really strange. First, I cannot reproduce the crash on
> MS-Windows, so the problem might be related to the shaping engine
> being used (I presume yours is libotf and libm17n). (I tried on both
> Windows XP and on Windows 7, which have very different versions of
> Uniscribe, and they both work fine.)
Yes, with ' --without-m17n-flt' it doesn't crash.
> Specifically, cmp_it.nbytes is computed in composition_update_it as
> the sum of byte-widths of all the characters being composed:
>
> cmp_it->width = 0;
> for (i = cmp_it->nchars - 1; i >= 0; i--)
> {
> c = XINT (LGSTRING_CHAR (gstring, cmp_it->from + i));
> cmp_it->nbytes += CHAR_BYTES (c);
> cmp_it->width += CHAR_WIDTH (c);
> }
I'm trying this:
=== modified file 'src/composite.c'
--- src/composite.c 2014-01-12 23:23:55 +0000
+++ src/composite.c 2014-01-17 07:16:11 +0000
@@ -24,6 +24,7 @@
#include <config.h>
+#include <stdio.h>
#include "lisp.h"
#include "character.h"
#include "buffer.h"
@@ -1410,9 +1411,16 @@
cmp_it->nchars = LGLYPH_TO (glyph) + 1 - from;
cmp_it->nbytes = 0;
cmp_it->width = 0;
+
+ fprintf (stderr, "%s: from %d, nchars %d, header %p is:\n", __func__,
+ cmp_it->from, cmp_it->nchars, XPNTR (LGSTRING_HEADER (gstring)));
+ debug_print (LGSTRING_HEADER (gstring));
+
for (i = cmp_it->nchars - 1; i >= 0; i--)
{
c = XINT (LGSTRING_CHAR (gstring, cmp_it->from + i));
+ fprintf (stderr, " at %d: char %d, %d bytes\n",
+ cmp_it->from + i, c, CHAR_BYTES (c));
cmp_it->nbytes += CHAR_BYTES (c);
cmp_it->width += CHAR_WIDTH (c);
}
And now seeing an illegal access beyond end of gstring header:
;; OK
composition_update_it: from 0, nchars 1, header 0x100c958 is:
[#<font-object "-unknown-PakType Naqsh-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1"> 1648 1583 1616 1593 1615 1608 1606 1614]
at 0: char 1648, 2 bytes
;; OK
composition_update_it: from 2, nchars 2, header 0x100c958 is:
[#<font-object "-unknown-PakType Naqsh-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1"> 1648 1583 1616 1593 1615 1608 1606 1614]
at 3: char 1593, 2 bytes
at 2: char 1616, 2 bytes
;; OK
composition_update_it: from 4, nchars 2, header 0x100c958 is:
[#<font-object "-unknown-PakType Naqsh-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1"> 1648 1583 1616 1593 1615 1608 1606 1614]
at 5: char 1608, 2 bytes
at 4: char 1615, 2 bytes
;; OK
composition_update_it: from 6, nchars 1, header 0x100c958 is:
[#<font-object "-unknown-PakType Naqsh-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1"> 1648 1583 1616 1593 1615 1608 1606 1614]
at 6: char 1606, 2 bytes
;; BAD
composition_update_it: from 7, nchars 2, header 0x100c958 is:
[#<font-object "-unknown-PakType Naqsh-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1"> 1648 1583 1616 1593 1615 1608 1606 1614]
at 8: char 2, 1 bytes
at 7: char 1614, 2 bytes
IIUC 2 is the garbage at (presumably invalid) position 8.
> And the characters in the LGSTRING object are simply copied from the
> buffer in fill_gstring_header, when LGSTRING is created:
>
> for (i = 0; i < len; i++)
> {
> int c;
>
> if (NILP (string))
> FETCH_CHAR_ADVANCE_NO_CHECK (c, from, from_byte);
> else
> FETCH_STRING_CHAR_ADVANCE_NO_CHECK (c, string, from, from_byte);
> ASET (header, i + 1, make_number (c));
> }
AFAICS gstring header is correct here.
> Btw, does the problem go away if you disable cache-long-scans?
No.
Dmitry
next prev parent reply other threads:[~2014-01-17 7:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 17:24 bug#16457: 24.3.50; crash rendering Arabic Uthmani script Dmitry Antipov
2014-01-15 17:41 ` Eli Zaretskii
2014-01-15 21:44 ` Glenn Morris
2014-01-16 8:01 ` Dmitry Antipov
2014-01-16 10:07 ` Dmitry Antipov
2014-01-16 17:33 ` Eli Zaretskii
2014-01-16 17:33 ` Eli Zaretskii
2014-01-17 7:34 ` Dmitry Antipov [this message]
2014-01-17 9:10 ` Eli Zaretskii
2014-01-17 11:16 ` Dmitry Antipov
2014-01-17 12:03 ` Eli Zaretskii
2014-01-17 13:51 ` K. Handa
2014-01-19 13:45 ` K. Handa
2014-01-19 16:00 ` Dmitry Antipov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D8DCF3.5030603@yandex.ru \
--to=dmantipov@yandex.ru \
--cc=16457@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).