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

["Richard M. Stallman" <rms@gnu.org>]

    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.