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: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Date: Fri, 16 Dec 2005 22:14:27 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1134770545 16023 80.91.229.2 (16 Dec 2005 22:02:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2005 22:02:25 +0000 (UTC) Cc: jasonr@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 23:02:22 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EnNbt-0002kW-60 for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2005 22:59:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnNcb-0002CF-76 for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2005 17:00:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EnLzt-00062H-W9 for emacs-devel@gnu.org; Fri, 16 Dec 2005 15:16:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EnLzr-00060s-Ht for emacs-devel@gnu.org; Fri, 16 Dec 2005 15:16:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnLzr-00060i-4o for emacs-devel@gnu.org; Fri, 16 Dec 2005 15:16:07 -0500 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EnM1U-0008T4-9H; Fri, 16 Dec 2005 15:17:48 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-64-110.inter.net.il [80.230.64.110]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DER00233 (AUTH halo1); Fri, 16 Dec 2005 22:14:25 +0200 (IST) Original-To: rms@gnu.org In-reply-to: (rms@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: news.gmane.org gmane.emacs.devel:47901 Archived-At: FWIW, I found that I can prevent this crash with the simple change below. It registers the frame in Vframe_alist before the menu bar is constructed, so if the latter signals an error, the frame whose menu could not be built is nonetheless recorded in Vframe_alist, and thus check_glyph_memory will free its glyph matrices. The question is: is the crash an artifact of how check_glyph_memory checks for glyph memory leaks, or does the crash indicate some deeper problem? In other words, is it kosher for Fx_create_frame to be entered recursively? Note that the version of Fx_create_frame in xfns.c creates the menu _after_ the frame is registered, and not as part of the window creation in x_window. Jason, can you tell whether it is okay to move the code that creates the menu on w32 from w32_window to Fx_create_frame, and do that after the call to x_icon and x_make_gc? Index: src/w32fns.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v retrieving revision 1.261 diff -c -r1.261 w32fns.c *** src/w32fns.c 14 Dec 2005 20:58:33 -0000 1.261 --- src/w32fns.c 16 Dec 2005 20:03:49 -0000 *************** *** 4299,4312 **** tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN); f->no_split = minibuffer_only || EQ (tem, Qt); w32_window (f, window_prompting, minibuffer_only); x_icon (f, parameters); - x_make_gc (f); /* Now consider the frame official. */ FRAME_W32_DISPLAY_INFO (f)->reference_count++; - Vframe_list = Fcons (frame, Vframe_list); /* We need to do this after creating the window, so that the icon-creation functions can say whose icon they're describing. */ --- 4299,4315 ---- tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN); f->no_split = minibuffer_only || EQ (tem, Qt); + /* Do this before the call to w32_window, since that can call Feval + (e.g., to compute the frame's menu bar) and throw an error, which + will leave this frame unregistered. */ + Vframe_list = Fcons (frame, Vframe_list); + w32_window (f, window_prompting, minibuffer_only); x_icon (f, parameters); x_make_gc (f); /* Now consider the frame official. */ FRAME_W32_DISPLAY_INFO (f)->reference_count++; /* We need to do this after creating the window, so that the icon-creation functions can say whose icon they're describing. */