From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: emacs crash Date: Thu, 04 Nov 2004 18:05:01 +0100 Message-ID: <418A613D.5050706@swipnet.se> References: <4188AB08.2000206@freemail.hu> <4188B2DB.9050005@gnu.org> <68c73b1a04110303066eac8188@mail.gmail.com> <4188F2F8.3000105@freemail.hu> <418A0512.3000901@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099587950 22626 80.91.229.6 (4 Nov 2004 17:05:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Nov 2004 17:05:50 +0000 (UTC) Cc: "B. Anyos" , chenggao@gmail.com, rms@gnu.org, Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 04 18:05:38 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CPl3J-0000to-00 for ; Thu, 04 Nov 2004 18:05:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CPlBT-0007iP-DE for ged-emacs-devel@m.gmane.org; Thu, 04 Nov 2004 12:14:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CPlBH-0007h0-ED for emacs-devel@gnu.org; Thu, 04 Nov 2004 12:13:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CPlBD-0007gb-EK for emacs-devel@gnu.org; Thu, 04 Nov 2004 12:13:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CPlBD-0007gV-Bs for emacs-devel@gnu.org; Thu, 04 Nov 2004 12:13:47 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CPl2j-0002Qe-Tx; Thu, 04 Nov 2004 12:05:02 -0500 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep01.bredband.com with ESMTP id <20041104170500.XVCA4883.mxfep01.bredband.com@coolsville.localdomain>; Thu, 4 Nov 2004 18:05:00 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: sv, en-us, en Original-To: emacs-devel@gnu.org In-Reply-To: <418A0512.3000901@gnu.org> 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: main.gmane.org gmane.emacs.devel:29438 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29438 Jason Rumney wrote: > Richard Stallman wrote: > >> For instance, there is something really strange here: >> >> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 >> + 17 bytes >> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes >> call1(int 556794192, int -2127346688) line 2547 + 11 bytes >> Fx_create_frame(int 0) line 4355 >> >> There is no call to Fx_create_frame in line 4355; in fact, line 4355 >> is far after the end of Fx_create_frame. What's going on? >> > I think the user is on Windows, so that would be line 4355 of w32fns.c, > which is in Fx_create_frame. > > My line numbers are slightly out, but I suspect this line (4350 in my > version): > > /* Set up faces after all frame parameters are known. This call > also merges in face attributes specified for new frames. If we > don't do this, the `menu' face for instance won't have the right > colors, and the menu bar won't appear in the specified colors for > new frames. */ > call1 (Qface_set_after_frame_default, frame); > > > It appears to be outside the BLOCK_INPUT blocks within x_create_frame. It is outside the BLOCK_INPUT in x_create_frame, but inside another BLOCK_INPUT. Installed cygwin, and tried to build. Here is what I get: #19 0x0114b433 in realize_x_face (cache=0x1b86140, attrs=0x82ec40, c=0, base_face=0x0) at xfaces.c:7141 #20 0x0114b2ce in realize_face (cache=0x1b86140, attrs=0x82ec40, c=0, base_face=0x0, former_face_id=0) at xfaces.c:7040 #21 0x0114ac0b in realize_default_face (f=0x16ce800) at xfaces.c:6967 #22 0x0114a942 in realize_basic_faces (f=0x16ce800) at xfaces.c:6834 #23 0x01149879 in Fdisplay_supports_face_attributes_p (attributes=23649197, display=23914500) at xfaces.c:6132 #24 0x0101c9c6 in Ffuncall (nargs=3, args=0x82ede0) at eval.c:2760 #25 0x0110491e in Fbyte_code (bytestr=18487971, vector=18488188, maxdepth=40) at bytecode.c:686 #26 0x0101cdac in funcall_lambda (fun=18487924, nargs=2, arg_vector=0x82ef24) at eval.c:2944 Number 23: Fdisplay_supports_face_attributes_p calls realize_basic_faces, which does BLOCK_INPUT before calling realize_default_face. xbacktrace: "replace-regexp-in-string" "tty-color-canonicalize" "tty-color-desc" "display-supports-face-attributes-p" "face-spec-set-match-display" "face-spec-choose" "face-spec-set" "byte-code" "face-set-after-frame-default" "x-create-frame" "x-create-frame-with-faces" "make-frame" "frame-initialize" "command-line" "normal-top-level" Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"? The other platforms (Mac and X) does not. NOTE: I am not at all familiar with W32, there might be a good reason. Jan D.