From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Hall Newsgroups: gmane.emacs.bugs Subject: Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep) Date: Mon, 04 Feb 2008 00:32:24 -1000 Message-ID: References: <47A6D110.2010206@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Generated by Pantomime 1.2.0) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Trace: ger.gmane.org 1202120972 32132 80.91.229.12 (4 Feb 2008 10:29:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2008 10:29:32 +0000 (UTC) Cc: Emacs bugs , Dan Nicolaescu To: Jason Rumney Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 04 11:29:53 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JLyaH-0000ot-I6 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2008 11:29:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLyZp-0003Oo-In for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2008 05:29:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JLyZ1-0003GH-LF for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2008 05:28:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JLyYx-0003Ev-J2 for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2008 05:28:34 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLyYx-0003Ei-0P for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2008 05:28:31 -0500 Original-Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JLyYr-0006Ci-2c; Mon, 04 Feb 2008 05:28:25 -0500 Original-Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4FED58325C; Mon, 4 Feb 2008 05:28:22 -0500 (EST) Original-Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 04 Feb 2008 05:28:22 -0500 X-Sasl-enc: LLztX85RN6XAR4olxF2JRaJiL6awSY9nROxA1YgA9Ie7 1202120901 Original-Received: from localhost.localdomain (75-95-220-61.hon.clearwire-dns.net [75.95.220.61]) by mail.messagingengine.com (Postfix) with ESMTP id E38AC9EB2; Mon, 4 Feb 2008 05:28:21 -0500 (EST) Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain ident=cjh) by localhost.localdomain with esmtp (Exim 4.50) id 1JLyci-000261-Lg; Mon, 04 Feb 2008 00:32:24 -1000 In-Reply-To: <47A6D110.2010206@gnu.org> User-Agent: GNUMail (Version 1.2.0) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:17472 Archived-At: >> With the patch I supplied, at least the user knows there is an issue >> with >> realizing the default face, rather than SIGSEGV (11). > Since this is a programming error in an internal structure, in a > development > version of the code, it is letting the developer know there is an > error. > Developers have debuggers, they don't need code to catch bugs and > exit > gracefully. To write code to catch every potential NULL pointer > exception in > the internal structures would make Emacs bloated and slow. > Thanks, but I think I already pretty much understood that. If I may quote myself: >>> I am aware that sometimes some classes of errors are perhaps best >>> allowed to >>> happen and to result in catastrophic failures like segmentation >>> faults, From an uninitiated point of view, I saw an attempt to reference a member of an uninitialized structure, while in the process of initializing, as you point out, a development version of the program. Based on the program's subsequent behavior, this structure is clearly *required* to be properly initialized in order to successfully realize a face, during the first call to 'Fdisplay_supports_face_attributes_p'. Further, the struct in question is called 'face_cache', which suggests to me that once one has realized a face, one can cache a reference to it in this struct. And further suggests to me that before realizing a face, one would have no need of a cache, so why go to the trouble of initializing it, if one wasn't yet sure whether a face even *could* be realized? (Never mind *requiring* it to be initialized.) Yet this struct clearly needs to be properly initialized as a necessary prerequisite of realizing a face. Maybe this is part of some sort of optimization, i.e., by delaying attempting to realize a face until the first time someone asks if the display supports face attributes? Or am I perhaps misinterpreting the name/purpose of the struct? TIA, Chris Hall