From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Problem report #16 Date: Thu, 13 Apr 2006 20:21:33 +0900 Message-ID: References: <200604111548.k3BFmtRQ015112@scanner2.ics.uci.edu> <200604121741.k3CHfRrO029529@amrm2.ics.uci.edu> <41269.128.165.123.132.1144866216.squirrel@webmail.lanl.gov> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1144927316 14036 80.91.229.2 (13 Apr 2006 11:21:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 Apr 2006 11:21:56 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 13 13:21:55 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FTzta-0000O9-Oz for ged-emacs-devel@m.gmane.org; Thu, 13 Apr 2006 13:21:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTzta-0005ir-3a for ged-emacs-devel@m.gmane.org; Thu, 13 Apr 2006 07:21:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTztM-0005ho-0r for emacs-devel@gnu.org; Thu, 13 Apr 2006 07:21:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTztK-0005gz-Sq for emacs-devel@gnu.org; Thu, 13 Apr 2006 07:21:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTztK-0005gt-Nf for emacs-devel@gnu.org; Thu, 13 Apr 2006 07:21:38 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FTzyd-0005F2-BH for emacs-devel@gnu.org; Thu, 13 Apr 2006 07:27:07 -0400 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3DBLZ79024833; Thu, 13 Apr 2006 20:21:35 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3DBLYDc022587; Thu, 13 Apr 2006 20:21:35 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1FTztF-0005qT-00; Thu, 13 Apr 2006 20:21:33 +0900 Original-To: herring@lanl.gov In-reply-to: <41269.128.165.123.132.1144866216.squirrel@webmail.lanl.gov> (herring@lanl.gov) 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:52821 Archived-At: In article <41269.128.165.123.132.1144866216.squirrel@webmail.lanl.gov>, "Stuart D. Herring" writes: > There's actually several possible problems here. >> > At conditional (1): "face != 0" taking false path >> > >> > 667 if (face) >> > 668 id = face->fontset; > This is a red herring -- face is reassigned later. Why? face is reassigned as a temporary value folder just before return (L686). >> > At conditional (2): "id < 0" taking true path >> > >> > 669 if (id < 0) >> > 670 fontset = Qnil; >> > 671 else >> > 672 fontset = FONTSET_FROM_ID (id); > Here's one thing I don't like: FONTSET_FROM_ID doesn't do any safety > checks on id. Can we trust this function to always get reasonable id > values? That's the other way round. FONTSET_FROM_ID should be called only when ID is valid. And, here, it is assured; that is to say, if face != NULL, face->fontset must be -1 or valid, and if face == NULL, the given ID must be -1 or valid. >> > 682 int face_id = XINT (elt); >> > 684 xassert (face_id == face->id); > Dan wrote (although not here in his message): >> This problem could happen if fs_load_font was called with face=NULL >> and id>0. Can that happen? > Here's where Dan's point is relevant: if face==NULL and id>0, then it > seems quite possible for this line to be reached... >> > 685 face = FACE_FROM_ID (f, face_id); There is just one place calling fs_load_font() with face==NULL and id>=0; list_fontsets() in fontset.c. But that function calls fs_load_font() (via FS_LOAD_FONT macro) only if BASE_FONTSET_P (fontset) is true, in which case, this line is never reached. > ...just before assigning face, so it'd still be NULL. But there's more: > FACE_FROM_ID can fail and return NULL: >> > Event var_deref_op: Variable "face" tracked as NULL was dereferenced. >> > Also see events: [var_compare_op] >> > >> > 686 return (*get_font_info_func) (f, face->font_info_id); > So this part is dangerous if and only if face_id, derived from the > fontset, can be messed up. face_id derived from the fontset should be always valid. If not, that means there's a bug somewhere else. Anyway, fs_load_font() is now very complicated because of repeated changes in the long history. So, I rewrote fontset.c in emacs-unicode-2 branch. It will be helpful if the similar report is issued on that branch because it contains many new codes. --- Kenichi Handa handa@m17n.org