Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]

[Eli Zaretskii <eliz@gnu.org>]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Wed, 14 Dec 2005 21:09:16 -0500
> 
>     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.

No, the stack is not corrupted.  The problem is that latest versions
of GDB modified their way of analyzing function prologues, and that
caused major regressions in stack backtraces on x86, especially with
latest versions of GCC.  That has been discussed extensively on the
GDB mailing list during the last year.

GDB 6.4 is supposed to improve on that, but I don't yet have its
Windows port.