unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: lekktu@gmail.com, cyd@stupidchicken.com, emacs-devel@gnu.org
Cc: Kenichi Handa <handa@m17n.org>
Subject: Re: Emacs 23.1.93 pretest
Date: Sat, 27 Feb 2010 16:14:08 +0200	[thread overview]
Message-ID: <83ocjadavj.fsf@gnu.org> (raw)
In-Reply-To: <83pr3qddl4.fsf@gnu.org>

> Date: Sat, 27 Feb 2010 15:15:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Thanks.  I get a similar crash, but it isn't an assert violation.
> 
>   Program received signal SIGSEGV, Segmentation fault.
>   0x0118191d in uniscribe_check_otf (font=0x3, otf_spec=44922882)
>       at w32uniscribe.c:684
>   684         features[1] = XCAR (rest);
> 
> otf_spec is nil in my case:
> 
>   (gdb) p otf_spec
>   $1 = 44922882
>   (gdb) xtype
>   Lisp_Symbol
>   (gdb) xsymbol
>   $2 = (struct Lisp_Symbol *) 0x2ad7800
>   "nil"

This sounds like a separate problem, though: it did not exist in
revision 99563 (from yesterday's noon [UTC+2]), but exists in the
current revision 99569 and in the pretest.  By contrast, the problem
with emacs-mule decoding exists in both revisions.

> But then how come this defense in uniscribe_check_otf did not catch
> it?
> 
>   /* Check the spec is in the right format.  */
>   if (!CONSP (otf_spec) || Flength (otf_spec) < 3)
>     return 0;

Answering my own question here: because otf_spec is a cons cell of the
right length, but it looks not according to what uniscribe_check_otf
expects:

    (gdb) p otf_spec
    $7 = 19320654
    (gdb) xcons
    $8 = (struct Lisp_Cons *) 0x126cf48
    {
      car = 0x2ec7fda,
      u = {
	cdr = 0x2ad7802,
	chain = 0x2ad7802
      }
    }
    (gdb) p otf_spec
    $9 = 19320654
    (gdb) xcdr
    $10 = 0x2ad7802
    (gdb) xcdr
    $11 = 0x0

The change which causes it is this:

  === modified file 'lisp/international/fontset.el'
  --- lisp/international/fontset.el       2010-01-13 08:35:10 +0000
  +++ lisp/international/fontset.el       2010-02-27 13:55:36 +0000
  @@ -415,6 +415,9 @@
	(sinhala ,(font-spec :registry "iso10646-1" :otf '(sinh nil (akhn))))
	(malayalam ,(font-spec :registry "iso10646-1" :otf '(mlym nil (akhn))))

  +     (myanmar ,(font-spec :registry "iso10646-1" :otf '(mymr))
  +             ,(font-spec :registry "iso10646-1" :script 'myanmar))
  +
	(lao ,(font-spec :registry "iso10646-1" :otf '(lao\  nil nil (mark)))
	    ,(font-spec :registry "iso10646-1" :script 'lao)
	    (nil . "MuleLao-1"))
  @@ -548,7 +551,6 @@
		      armenian
		      syriac
		      thaana
  -                   myanmar
		      georgian
		      cherokee
		      canadian-aboriginal

Perhaps Handa-san could take a look at this.  The entry you added
seems to violate the doc string of `font-spec', which says:

    `:otf'

    VALUE must be a list (SCRIPT-TAG LANGSYS-TAG GSUB [ GPOS ]) to specify
    required OpenType features.

      SCRIPT-TAG: OpenType script tag symbol (e.g. `deva').
      LANGSYS-TAG: OpenType language system tag symbol,
	 or nil for the default language system.
      GSUB: List of OpenType GSUB feature tag symbols, or nil if none required.
      GPOS: List of OpenType GPOS feature tag symbols, or nil if none required.

Btw, the `:otf' spec does not seem to be documented in the ELisp manual.




  reply	other threads:[~2010-02-27 14:14 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27  3:40 Emacs 23.1.93 pretest Chong Yidong
2010-02-27  9:05 ` Eli Zaretskii
2010-02-27 10:21   ` Eli Zaretskii
2010-02-27 11:28     ` Juanma Barranquero
2010-02-27 12:11       ` Juanma Barranquero
2010-02-27 13:15         ` Eli Zaretskii
2010-02-27 14:14           ` Eli Zaretskii [this message]
2010-02-27 14:31           ` Andreas Schwab
2010-02-27 14:54             ` Eli Zaretskii
2010-02-27 14:59               ` Lennart Borgman
2010-02-27 15:29                 ` Eli Zaretskii
2010-02-27 15:22           ` Chong Yidong
2010-02-27 18:58             ` Eli Zaretskii
2010-03-04 11:32             ` Kenichi Handa
2010-03-04 12:35               ` Jason Rumney
2010-02-27 15:39           ` Juanma Barranquero
2010-02-27 19:41           ` Stefan Monnier
2010-02-27 11:57     ` Eli Zaretskii
2010-02-27 19:03       ` Eli Zaretskii
2010-02-27 21:37         ` Chong Yidong
2010-02-27 22:22           ` Eli Zaretskii
2010-02-28  1:25             ` Chong Yidong
2010-02-28 17:21               ` Eli Zaretskii
2010-02-28  1:45             ` Chong Yidong
2010-02-28 10:46               ` Andreas Schwab
2010-02-28 14:25                 ` Chong Yidong
2010-02-28 15:38                   ` Andreas Schwab
2010-02-28 17:32                   ` Eli Zaretskii
2010-02-28 19:31                     ` Eli Zaretskii
2010-03-02 18:15                       ` Eli Zaretskii
2010-03-02 19:53                         ` Chong Yidong
2010-03-02 20:53                           ` Eli Zaretskii
2010-03-04 11:24                             ` Kenichi Handa
2010-02-28 17:34                   ` Eli Zaretskii
2010-02-28 21:34                     ` Chong Yidong
2010-02-28 17:15               ` Eli Zaretskii
2010-03-02 15:42 ` Drew Adams
2010-03-02 16:02   ` Chong Yidong
2010-03-02 18:35     ` Drew Adams
2010-03-02 19:53       ` Chong Yidong
2010-03-04 14:36 ` bug#5679: " Sergei Organov
  -- strict thread matches above, loose matches on Subject: below --
2010-04-03  1:13 Chong Yidong
2010-04-03  1:34 ` Juanma Barranquero
2010-04-03  2:36   ` Chong Yidong
2010-04-03  2:38     ` Juanma Barranquero
2010-04-03  9:33       ` Eli Zaretskii
2010-04-03 12:45       ` Sean Sieger
2010-04-03 13:53         ` Eli Zaretskii
2010-04-03 15:06         ` Chong Yidong
2010-04-03 15:52           ` Eli Zaretskii
2010-04-03  1:45 ` Sean Sieger
2010-04-03  7:01 ` Eli Zaretskii
2010-04-03  8:26 ` Eli Zaretskii
2010-04-04 19:22 ` Drew Adams
2010-04-05  0:48   ` Sean Sieger
2010-04-11 18:30     ` Uwe Siart
2010-04-11 18:34       ` Uwe Siart
2010-04-05  9:33 ` Eduard Wiebe

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=83ocjadavj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=handa@m17n.org \
    --cc=lekktu@gmail.com \
    /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).