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: Wed, 14 Dec 2005 21:38:37 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1134598413 24043 80.91.229.2 (14 Dec 2005 22:13:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2005 22:13:33 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 14 23:13:25 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Emepp-0003Vo-V8 for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 23:10:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmeqR-0002KA-Nz for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 17:11:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EmcTS-00068U-KQ for emacs-devel@gnu.org; Wed, 14 Dec 2005 14:39:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EmcTP-00066f-ND for emacs-devel@gnu.org; Wed, 14 Dec 2005 14:39:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmcTP-00066Y-GN for emacs-devel@gnu.org; Wed, 14 Dec 2005 14:39:35 -0500 Original-Received: from [192.114.186.17] (helo=gandalf.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EmcVO-0002Rp-UA; Wed, 14 Dec 2005 14:41:39 -0500 Original-Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HGO07187; Wed, 14 Dec 2005 21:38:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-6-214.inter.net.il [80.230.6.214]) by nitzan.inter.net.il (MOS 3.7.2-GA) with ESMTP id CFN76384 (AUTH halo1); Wed, 14 Dec 2005 21:38:37 +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:47728 Archived-At: > From: "Richard M. Stallman" > CC: emacs-devel@gnu.org > Date: Tue, 13 Dec 2005 18:33:42 -0500 > > > #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, > > pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 > > #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, > > prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 > > (More stack frames follow...) > > > > You cut it off just as it's starting to get interesting! > > Tell me what you want to know or see, and I will make sure it's not > cut off. > > Where does it come from in Fx_create_frame? > > If there are two frames that call Fx_create_frame, I need > to see both. Unfortunately, I cannot show this in the C traceback, because GDB chokes on the next stack frame: #39 0x0112ae03 in single_menu_item (key=28443961, item=0, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9, notreal=17085537, maxdepth=24660221) at w32menu.c:468 #41 0x00000000 in ?? () from #42 0x00000009 in ?? () #43 0x0104b461 in parse_menu_item (item=480, notreal=8573128, inmenubar=18001130) at keyboard.c:7376 #44 0x01c76008 in ?? () #45 0x000001e0 in ?? () #46 0x0082d0c8 in ?? () #47 0x0112acea in grow_menu_items () at w32menu.c:329 #48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005 Cannot access memory at address 0x1b016c14 But the Lisp traceback clearly shows the recursive call: "x-create-frame" "x-create-frame-with-faces" "make-frame" "special-display-popup-frame" "pop-to-buffer" "byte-code" "debug" "and" "x-create-frame" "x-create-frame-with-faces" "make-frame" "special-display-popup-frame" "display-buffer" "display-warning" "byte-compile-log-warning" "byte-compile-warn" "byte-compile-variable-ref" "byte-compile-form" "byte-compile-body" "byte-compile-let" "byte-compile-form" "byte-compile-top-level" "byte-compile-lambda" 0x1c2cf24 PVEC_COMPILED "funcall" "byte-compile" "ad-compile-function" "ad-activate-advised-definition" "ad-activate" "byte-code" "require" "eval" "eval-last-sexp-1" "eval-last-sexp" "call-interactively" I think the recursion happens when Emacs builds the menu bar for the new frame. The C functions that build menu items, which show in the C traceback, are an evidence to that effect.