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: Wed, 14 Dec 2005 21:09:16 -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 1134612941 30659 80.91.229.2 (15 Dec 2005 02:15:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2005 02:15:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 03:15:37 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EmieS-0007n3-JZ for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2005 03:15:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emif4-0004wC-Lm for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 21:16:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Emiag-0001Lk-VF for emacs-devel@gnu.org; Wed, 14 Dec 2005 21:11:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Emiac-0001Ht-T1 for emacs-devel@gnu.org; Wed, 14 Dec 2005 21:11:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emiac-0001HB-CJ for emacs-devel@gnu.org; Wed, 14 Dec 2005 21:11:26 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Emicm-0002e1-RR for emacs-devel@gnu.org; Wed, 14 Dec 2005 21:13:40 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EmiYW-0002wy-OR; Wed, 14 Dec 2005 21:09:16 -0500 Original-To: Eli Zaretskii In-reply-to: (message from Eli Zaretskii on Wed, 14 Dec 2005 21:38:37 +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:47765 Archived-At: 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 This means the stack is corrupted. We need to find out why and how, because that could be the most important bug. This is probably straightforward and not too hard. It has to happen inside that call to x_y_to_hpos_vpos. By inserting some breakpoints at places where control passes within that frame, and at each one examining the backtrace, you can see it gets clobbered between point X and point Y. Then try again with breakpoints or stepping between X and Y, and localize it more narrowly. Eventually you find exactly where it happens, and the problem is usually obvious when you look at the code in that line.