From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Date: Fri, 16 Dec 2005 20:05:24 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1134782217 14402 80.91.229.2 (17 Dec 2005 01:16:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2005 01:16:57 +0000 (UTC) Cc: jasonr@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 17 02:16:56 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EnQfi-0000Pk-Bj for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2005 02:15:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnQgP-0001TD-Tu for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2005 20:16:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EnQYC-0005Pj-3y for emacs-devel@gnu.org; Fri, 16 Dec 2005 20:07:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EnQY8-0005Nw-56 for emacs-devel@gnu.org; Fri, 16 Dec 2005 20:07:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnQY3-0005NE-UD for emacs-devel@gnu.org; Fri, 16 Dec 2005 20:07:47 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EnQaZ-0005lZ-N6 for emacs-devel@gnu.org; Fri, 16 Dec 2005 20:10:19 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EnQVo-0005A3-B5; Fri, 16 Dec 2005 20:05:24 -0500 Original-To: Eli Zaretskii In-reply-to: (message from Eli Zaretskii on Fri, 16 Dec 2005 22:14:27 +0200) 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:47922 Archived-At: + /* 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); Changing Vframe_list so early, before calling w32_window, could be dangerous. What if some part of window creation fails, or x_icon, or x_make_gc? While I am not sure of how things worn on Windows, if those fail I suspect it will leave a bad situation. You would not want such a frame to be considered live. I think the right fix is keep the setting of Vframe_list where it was, and instead move the creation of the menu bar out of w32_window and put it at a later place in Fx_create_frame. That would make the code more like what it is in xfns.c, where the menu bar creation step is done later, after the frame is already safely in existence.