From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs 23.1.93 pretest Date: Sat, 27 Feb 2010 16:14:08 +0200 Message-ID: <83ocjadavj.fsf@gnu.org> References: <87pr3rny7e.fsf@stupidchicken.com> <83fx4n122q.fsf@gnu.org> <833a0ndlo0.fsf@gnu.org> <83pr3qddl4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1267280081 9095 80.91.229.12 (27 Feb 2010 14:14:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Feb 2010 14:14:41 +0000 (UTC) Cc: Kenichi Handa To: lekktu@gmail.com, cyd@stupidchicken.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 27 15:14:36 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NlNR4-0005AF-99 for ged-emacs-devel@m.gmane.org; Sat, 27 Feb 2010 15:14:26 +0100 Original-Received: from localhost ([127.0.0.1]:55555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlNR3-0005tf-FM for ged-emacs-devel@m.gmane.org; Sat, 27 Feb 2010 09:14:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlNQy-0005sC-Sv for emacs-devel@gnu.org; Sat, 27 Feb 2010 09:14:20 -0500 Original-Received: from [140.186.70.92] (port=39039 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlNQx-0005qh-Ml for emacs-devel@gnu.org; Sat, 27 Feb 2010 09:14:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NlNQw-0005iF-FW for emacs-devel@gnu.org; Sat, 27 Feb 2010 09:14:19 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:34721) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NlNQw-0005i5-4B for emacs-devel@gnu.org; Sat, 27 Feb 2010 09:14:18 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KYI00H006XXYQ00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 27 Feb 2010 16:14:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.228.186.130]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KYI00H727JCQC20@a-mtaout20.012.net.il>; Sat, 27 Feb 2010 16:14:01 +0200 (IST) In-reply-to: <83pr3qddl4.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121434 Archived-At: > Date: Sat, 27 Feb 2010 15:15:35 +0200 > From: Eli Zaretskii > 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.