Re: address@hidden: RE: weird defadvice bug with byte-compilation]

[Eli Zaretskii]

> From: "Richard M. Stallman" <address@hidden>
> CC: address@hidden
> 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.