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

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

[Richard Stallman]

Would someone please investigate this bug, and ack?
It needs to be debugged for the release.

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Tue, 22 Nov 2005 09:32:25 -0800
In-Reply-To: <MEEKKIABFKKDFJMPIOEBKEHKCNAA.drew.adams@oracle.com>
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
Subject: RE: weird defadvice bug with byte-compilation
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Not sure if anyone is looking into this bug. I know it sounds as if it's
quite particular (corner case), but I suspect that this may point to
something improper in the byte-compiler code. And it does systematically
produce a fatal error. - Drew

- ----------

    This is a weird one. I've pared it down to the bare bones, I think -
    if I comment out any part of this, the bug doesn't occur. This
    obviously comes from a larger context - when it is pared down, the
    code doesn't make much sense, of course.

    If the stuff is in the same file, or the order is different, no bug
    (error). It must be like this: two files, one of which is compiled and
    required by the other. And the requiring file must have "compile" in
    its defadvice.

    Two files:

    File 1: foo.el
    --------------

    (defvar mymap nil "")

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))
      (push (cons 'my-mode mymap) minor-mode-map-alist))

    (defadvice next-history-element (after ffff activate) "" my-mode)

    (provide 'foo)

    File 2: bar.el
    --------------

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

    (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
    (setq load-path (append (list drews-lisp-dir) load-path))


    (defadvice occur-mode-goto-occurrence
      (around jjjjjj activate compile)
      ""
      ad-do-it)

    (require 'foo)

    Instructions:
    -------------

    1. emacs -q

    2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
       or 22). `C-x C-c'.

    3. emacs -q    (Emacs 22)

    4. Visit bar.el - don't load it.

    5. Select everything in bar.el except the (require 'foo), and
    do `eval-region'.

    6. Put the cursor just after the (require 'foo) and do `C-x
    C-e'. (Don't select it and do eval-region - that doesn't
    produce the bug!)

    You will get this error backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80)
    (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80)
    (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable
    `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable
    `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq
    ad-return-value (ad-Orig-next-history-element n)) my-mode
    ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq
    ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc:
    next-history-element$" (interactive "p") (let (ad-return-value)
    (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "???			\n
    \f
    \x0e\x0e??


    7. `C-x C-c'

    You will get a pop-up message with Yes/No buttons that says this:

    Emacs Abort Dialog

    "A fatal error has occurred! Would you like to attach a
    debugger? Select YES to debu, NO to abort Emacs"

    If you select Yes, you get a Window program exception and an
    invitation to send the details to Microsoft. The error report
    contents are these:

    Exception Information
    Code 0x80000003 Flags: 0x00000000
    Record: 0x0000000000000000 (didn't count 'em) Address:
    0x0000000077f75a58

    System Information
    Windows NT 5.1 Build: 2600
    CPU Vendor Code etc. blah blah blah

    Module 1
    emacs.exe
    blah blah

    Module 2
    ntdll.dll
    blah blah

    Module 3
    kernel32.dll
    blah blah

    Module 4
    msvcrt.dll
    blah blah

    etc. etc.

    ------------------------------------
    In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
     of 2005-06-26 on NONIQPC
    X server distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.3) --cflags
    -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
    -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
    -I../../zlib-1.2.2/include'





_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

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

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Would someone please investigate this bug, and ack?
> It needs to be debugged for the release.

I can't seem to reproduce this on GNU/Linux.  It may be a Windows-only
bug (unless it's been fixed already).

> From: "Drew Adams" <drew.adams@oracle.com>
>
>     File 1: foo.el
>     --------------
>
>     (defvar mymap nil "")
>
>     (let ((map (make-sparse-keymap "II")))
>       (setq mymap (make-sparse-keymap))
>       (define-key menu-bar-search-menu [ise]  '("" . ise))
>       (put 'ise 'menu-enable '(and my-mode))
>       (push (cons 'my-mode mymap) minor-mode-map-alist))
>
>     (defadvice next-history-element (after ffff activate) "" my-mode)
>
>     (provide 'foo)
>
>     File 2: bar.el
>     --------------
>
>     (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))
>
>     (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
>     (setq load-path (append (list drews-lisp-dir) load-path))
>
>
>     (defadvice occur-mode-goto-occurrence
>       (around jjjjjj activate compile)
>       ""
>       ad-do-it)
>
>     (require 'foo)
>
>     Instructions:
>     -------------
>
>     1. emacs -q
>
>     2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
>        or 22). `C-x C-c'.
>
>     3. emacs -q    (Emacs 22)
>
>     4. Visit bar.el - don't load it.
>
>     5. Select everything in bar.el except the (require 'foo), and
>     do `eval-region'.
>
>     6. Put the cursor just after the (require 'foo) and do `C-x
>     C-e'. (Don't select it and do eval-region - that doesn't
>     produce the bug!)
>
>     7. `C-x C-c'
>
>     You will get a pop-up message with Yes/No buttons that says this:
>
>     Emacs Abort Dialog
>
>     "A fatal error has occurred! Would you like to attach a
>     debugger? Select YES to debu, NO to abort Emacs"

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

[Richard M. Stallman]

    > Would someone please investigate this bug, and ack?
    > It needs to be debugged for the release.

    I can't seem to reproduce this on GNU/Linux.  It may be a Windows-only
    bug (unless it's been fixed already).

Thanks for investigating.  It could be fixed already.
So we can forget about it unless we get a new report
based on the latest sources.

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

[Drew Adams]

        > Would someone please investigate this bug, and ack?
        > It needs to be debugged for the release.

        I can't seem to reproduce this on GNU/Linux.  It may be a
        Windows-only bug (unless it's been fixed already).

    Thanks for investigating.  It could be fixed already.
    So we can forget about it unless we get a new report
    based on the latest sources.

Yes, thanks for looking into it. Hopefully it was already fixed, and is not
a Windows-specific problem.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 8 Dec 2005 08:14:55 -0800
> 
>         > Would someone please investigate this bug, and ack?
>         > It needs to be debugged for the release.
> 
>         I can't seem to reproduce this on GNU/Linux.  It may be a
>         Windows-only bug (unless it's been fixed already).
> 
>     Thanks for investigating.  It could be fixed already.
>     So we can forget about it unless we get a new report
>     based on the latest sources.
> 
> Yes, thanks for looking into it. Hopefully it was already fixed, and is not
> a Windows-specific problem.

I'm not sure it was fixed.  Chong Yidong didn't say what he saw on
GNU/Linux when he tried this, but on MS-Windows, with today's CVS, I
see the following (after replacing "C:\\drews-lisp-20" with the
directory where I put foo.el and bar.el --- Chong, did you do that on
GNU/Linux?):

  . Typing "C-x C-e" to evaluate `(require 'foo)' throws an error:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc: next-history-element$" (interactive "p") (let (ad-return-value) (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "...."
      byte-compile(advice-compilation)
      ad-compile-function(next-history-element)
      ad-activate-advised-definition(next-history-element nil)
      ad-activate(next-history-element nil)
      byte-code("...")
      require(foo)
      eval((require (quote foo)))
      eval-last-sexp-1(nil)
      eval-last-sexp(nil)
      call-interactively(eval-last-sexp)

      (I omitted the byte-codes and replaced them with ellipsis "...".)

   .  Typing "C-x C-c" at this point, i.e., after the above traceback
      was shown, does pop up the Emacs Abort Dialog.

The Lisp error is thrown for a good reason, AFAICT: `my-mode' was
never defined.  Drew, should it be?

If I run Emacs from GDB, I get the following backtrace after I click
YES in the abort dialog:

    (gdb) bt 20
    #0  0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
    #1  0x011319c7 in w32_abort () at w32fns.c:8949
    #2  0x01084cee in check_glyph_memory () at dispnew.c:2583
    #3  0x010018c3 in shut_down_emacs (sig=0, no_x=0, stuff=23861249)
	at emacs.c:2167
    #4  0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2072
    #5  0x0100c5da in Ffuncall (nargs=1, args=0x82c1b0) at eval.c:2879
    #6  0x011094f9 in Fbyte_code (bytestr=18486379, vector=18486500, maxdepth=40)
	at bytecode.c:694
    #7  0x0100bfae in funcall_lambda (fun=18486332, nargs=1, arg_vector=0x82c374)
	at eval.c:3066
    #8  0x0100c3a1 in Ffuncall (nargs=2, args=0x82c370) at eval.c:2934
    #9  0x01107858 in Fcall_interactively (function=24463457,
	record_flag=23861249, keys=23920644) at callint.c:884
    #10 0x0104ca3e in Fcommand_execute (cmd=24463457, record_flag=23861249,
	keys=23861249, special=23861249) at keyboard.c:9734
    #11 0x01053279 in command_loop_1 () at keyboard.c:1777
    #12 0x0100a81b in internal_condition_case (bfun=0x1052f39 <command_loop_1>,
	handlers=23925361, hfun=0x104d397 <cmd_error>) at eval.c:1465
    #13 0x010479b7 in command_loop_2 () at keyboard.c:1315
    #14 0x0100a750 in internal_catch (tag=23949793,
	func=0x1047994 <command_loop_2>, arg=23861249) at eval.c:1211
    #15 0x0104777f in command_loop () at keyboard.c:1282
    #16 0x01047867 in recursive_edit_1 () at keyboard.c:987
    #17 0x0104797d in Frecursive_edit () at keyboard.c:1048
    #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876
    #19 0x011094f9 in Fbyte_code (bytestr=32152067, vector=27025668, maxdepth=32)
	at bytecode.c:694
    (More stack frames follow...)

    Lisp Backtrace:
    "kill-emacs"
    "save-buffers-kill-emacs"
    "call-interactively"
    "recursive-edit"
    "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"

I will try to debug this when I have time (any ideas are welcome), but
in the meantime, I see already that the problem that causes Emacs to
commit suicide in frame #2 is that glyph_matrix_count is 8 instead of
0.  Here's the code of check_glyph_memory:

    /* Check glyph memory leaks.  This function is called from
       shut_down_emacs.  Note that frames are not destroyed when Emacs
       exits.  We therefore free all glyph memory for all active frames
       explicitly and check that nothing is left allocated.  */

    void
    check_glyph_memory ()
    {
      Lisp_Object tail, frame;

      /* Free glyph memory for all frames.  */
      FOR_EACH_FRAME (tail, frame)
	free_glyphs (XFRAME (frame));

      /* Check that nothing is left allocated.  */
      if (glyph_matrix_count)
	abort ();
      if (glyph_pool_count)
	abort ();
    }

It sounds like some frame's glyph matrices were not freed for some
reason?

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

[Chong Yidong]

> I'm not sure it was fixed.  Chong Yidong didn't say what he saw on
> GNU/Linux when he tried this, but on MS-Windows, with today's CVS, I
> see the following (after replacing "C:\\drews-lisp-20" with the
> directory where I put foo.el and bar.el --- Chong, did you do that on
> GNU/Linux?):
>
>    .  Typing "C-x C-c" at this point, i.e., after the above traceback
>       was shown, does pop up the Emacs Abort Dialog.

On GNU/Linux, `C-x C-c' at this point just exits Emacs.  I didn't see
any abort dialog.

RE: [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation]

[Drew Adams]

    I'm not sure it was fixed.  Chong Yidong didn't say what he saw on
    GNU/Linux when he tried this, but on MS-Windows, with today's CVS, I
    see the following (after replacing "C:\\drews-lisp-20" with the
    directory where I put foo.el and bar.el --- Chong, did you do that on
    GNU/Linux?):

      . Typing "C-x C-e" to evaluate `(require 'foo)' throws an error:

        Debugger entered--Lisp error: (void-variable my-mode)...

      .  Typing "C-x C-c" at this point, i.e., after the above traceback
         was shown, does pop up the Emacs Abort Dialog.

Thanks fo looking into this problem on Windows. What Eli reports is exactly
what I saw and see.

    The Lisp error is thrown for a good reason, AFAICT: `my-mode' was
    never defined.  Drew, should it be?

Yes and no. Yes, for my program to work; no, to reproduce the bug. If it is
defined explicitly, then the error does not occur. (The error to be
concerned about here is obviously the fatal error that results, not the
error of the variable not being bound.)

Here is some background on the variable binding, however - the real context:

1. In file foo.el, I do the defadvice before I do a define-minor-mode that
defines (and binds) the variable my-mode. If I move the defadvice in foo.el
after the define-minor-mode, there is no problem. ("So", the doctor said,
"if it hurts, just don't do that".)

However, I'm not clear on why I should need to do that. Does the defadvice
really need my-mode to be bound? I thought that defadvice's last arg (BODY),
in this case just my-mode, was treated by defadvice as unevaluated code, to
be evaluated only when the advised function is called. In the case in
question, the function next-history-element is never called, so I don't
understand why my-mode is evaluated.

It is apparently evaluated by x-create-frame, but I don't see why. Looking
further up the debug stack, there is an automatic byte-compilation of the
advised next-history-element. It's not clear to me if the variable is
evaluated at that point or just by x-create-frame. I don't see why
x-create-frame would evaluate the variable, and I don't see why the variable
would be evaluated during byte-compilation.

2. Secondly, I'm not real clear on the use of define-minor-mode, I guess.
This library works with both Emacs 20 and 22. For Emacs 20, I do an explicit
defcustom to define my-mode, and I do that before defining the minor-mode
function my-mode - no problem. For Emacs 22, I do the define-minor-mode at
the same place I do the Emacs 20 defun my-mode.

I was expecting that define-minor-mode would DTRT: it would somehow define
the variable early enough - but I guess that's not possible. I will move the
define-minor-mode forward, but it makes the library a bit less readable. I
like to put all defcustoms and defvars at the beginning (after macro
definitions), before any function definitions. I think of define-minor-mode
as essentially a function definition, but it is in fact also a variable
definition, so I guess I need to move it forward.

You'll say that defadvice also (re)defines a function, and the only need
here is to move the define-minor-mode before the defadvice. That's true.
There was a certain logic to the order of the function definitions, but
that's less important now than making things work! I'll move the
define-minor-mode forward, and say no more.

That changes nothing about the bug, of course - Emacs should not end in a
fatal error just because a variable is not bound. And I still have the
question about why the unbound variable was evaluated (during advice
compilation? during frame creation?).

--

Oops - last minute addition. It just occurred to me that the unbound
variable is being evaluated by x-create-frame in order to set the minor-mode
mode-line indication. (Should users need to be concerned about binding that
variable, even though they have used define-minor-mode?) I think, then, that
there may be a second bug here, besides ungracefully treating an unbound
variable.

Again, however, there seem to be several things interacting here, because I
found that if I remove any part of the code I submitted with the bug, the
bug goes away. This suggests that it involves: 1) the mode-line indication
(minor-mode-map-alist), 2) the menu-enable condition (that's the code that
provokes the error message by evaluating the unbound variable), 3) the
keymap, 4) the defadvice in foo.el, and 5) the defadvice in bar.el.

Clarification welcome.

Thanks,

  Drew

    If I run Emacs from GDB, I get the following backtrace after I click
    YES in the abort dialog:

        (gdb) bt 20
        #0  0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
        #1  0x011319c7 in w32_abort () at w32fns.c:8949
        #2  0x01084cee in check_glyph_memory () at dispnew.c:2583
        #3  0x010018c3 in shut_down_emacs (sig=0, no_x=0, stuff=23861249)
    	at emacs.c:2167
        #4  0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2072
        #5  0x0100c5da in Ffuncall (nargs=1, args=0x82c1b0) at eval.c:2879
        #6  0x011094f9 in Fbyte_code (bytestr=18486379,
    vector=18486500, maxdepth=40)
    	at bytecode.c:694
        #7  0x0100bfae in funcall_lambda (fun=18486332, nargs=1,
    arg_vector=0x82c374)
    	at eval.c:3066
        #8  0x0100c3a1 in Ffuncall (nargs=2, args=0x82c370) at eval.c:2934
        #9  0x01107858 in Fcall_interactively (function=24463457,
    	record_flag=23861249, keys=23920644) at callint.c:884
        #10 0x0104ca3e in Fcommand_execute (cmd=24463457,
    record_flag=23861249,
    	keys=23861249, special=23861249) at keyboard.c:9734
        #11 0x01053279 in command_loop_1 () at keyboard.c:1777
        #12 0x0100a81b in internal_condition_case (bfun=0x1052f39
    <command_loop_1>,
    	handlers=23925361, hfun=0x104d397 <cmd_error>) at eval.c:1465
        #13 0x010479b7 in command_loop_2 () at keyboard.c:1315
        #14 0x0100a750 in internal_catch (tag=23949793,
    	func=0x1047994 <command_loop_2>, arg=23861249) at eval.c:1211
        #15 0x0104777f in command_loop () at keyboard.c:1282
        #16 0x01047867 in recursive_edit_1 () at keyboard.c:987
        #17 0x0104797d in Frecursive_edit () at keyboard.c:1048
        #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876
        #19 0x011094f9 in Fbyte_code (bytestr=32152067,
    vector=27025668, maxdepth=32)
    	at bytecode.c:694
        (More stack frames follow...)

        Lisp Backtrace:
        "kill-emacs"
        "save-buffers-kill-emacs"
        "call-interactively"
        "recursive-edit"
        "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"

    I will try to debug this when I have time (any ideas are welcome), but
    in the meantime, I see already that the problem that causes Emacs to
    commit suicide in frame #2 is that glyph_matrix_count is 8 instead of
    0.  Here's the code of check_glyph_memory:

        /* Check glyph memory leaks.  This function is called from
           shut_down_emacs.  Note that frames are not destroyed when Emacs
           exits.  We therefore free all glyph memory for all active frames
           explicitly and check that nothing is left allocated.  */

        void
        check_glyph_memory ()
        {
          Lisp_Object tail, frame;

          /* Free glyph memory for all frames.  */
          FOR_EACH_FRAME (tail, frame)
    	free_glyphs (XFRAME (frame));

          /* Check that nothing is left allocated.  */
          if (glyph_matrix_count)
    	abort ();
          if (glyph_pool_count)
    	abort ();
        }

    It sounds like some frame's glyph matrices were not freed for some
    reason?

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

[Richard M. Stallman]

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))

I think I see the reason for this error:

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))

The menu command's enable condition tests a void variable.
So this error seems to be correct.

    It sounds like some frame's glyph matrices were not freed for some
    reason?

Or maybe they were originally used, and counted, more times
than they should have been.

So I think the first question is, was glyph_matrix_count correct
before check_glyph_memory was called?  If so, there must be a bug in
free_glyphs.  If it was not correct, then how did it get to be wrong?

I suspect that it has to do with getting an error while
part way through creating a frame.  Maybe that left an inconsistent
value for glyph_matrix_count.

RE: [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation]

[Drew Adams]

        Debugger entered--Lisp error: (void-variable my-mode)

    I think I see the reason for this error:

        (let ((map (make-sparse-keymap "II")))
          (setq mymap (make-sparse-keymap))
          (define-key menu-bar-search-menu [ise]  '("" . ise))
          (put 'ise 'menu-enable '(and my-mode))

    The menu command's enable condition tests a void variable.
    So this error seems to be correct.

See my previous message - I already indicated that the menu-enable is
testing a void variable. The question is why it is void.

There are a couple of questions involved (see my email), including how
define-minor-mode works. My understanding was that define-minor-mode was
designed to replace an explicit defcustom or defvar for the mode variable
(my-mode), in addition to replacing an explicit definition of the minor-mode
toggle function. If that is the intention, then this case seems to point to
a hole in the implementation (?) - users of define-minor-mode must
nevertheless be concerned with also defining the mode variable, if they
explicitly use it in a menu-enable property.

And, again, there seem to be other things going on in this case, as well:

    If I remove any part of the code I submitted with the bug, the
    bug goes away. This suggests that it involves: 1) the mode-line
    indication (minor-mode-map-alist), 2) the menu-enable condition
    (that's the code that provokes the error message by evaluating
    the unbound variable), 3) the keymap, 4) the defadvice in foo.el,
    and 5) the defadvice in bar.el.

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

[Richard M. Stallman]

    See my previous message - I already indicated that the menu-enable is
    testing a void variable. The question is why it is void.

It is void because there is nothing in the code to set it.
Why do you think it would NOT be void?

    There are a couple of questions involved (see my email), including how
    define-minor-mode works.

What does this have to do with define-minor-mode?
Your code does not use define-minor-mode.

    File 1: foo.el
    --------------

    (defvar mymap nil "")

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))
      (push (cons 'my-mode mymap) minor-mode-map-alist))

    (defadvice next-history-element (after ffff activate) "" my-mode)

    (provide 'foo)

    File 2: bar.el
    --------------

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

    (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
    (setq load-path (append (list drews-lisp-dir) load-path))


    (defadvice occur-mode-goto-occurrence
      (around jjjjjj activate compile)
      ""
      ad-do-it)

    (require 'foo)

RE: [drew.adams@oracle.com: RE: weird defadvice bugwithbyte-compilation]

[Drew Adams]

        See my previous message - I already indicated that the
        menu-enable is testing a void variable. The question is
        why it is void.

    It is void because there is nothing in the code to set it.
    Why do you think it would NOT be void?

        There are a couple of questions involved (see my email),
        including how define-minor-mode works.

    What does this have to do with define-minor-mode?
    Your code does not use define-minor-mode.

Please see my previous emails, where I describe the original case (which
uses define-minor-mode). That may or may not be related to the crash, but it
is a question I have and perhaps a potential problem. There are additional
questions raised and problems mentioned in my previous emails on this.

Re: [drew.adams@oracle.com: RE: weird defadvice bugwithbyte-compilation]

[Richard M. Stallman]

    Please see my previous emails, where I describe the original case (which
    uses define-minor-mode).

Could you send that test case again?

RE: [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation]

[Drew Adams]

        Please see my previous emails, where I describe the
        original case (which uses define-minor-mode).

    Could you send that test case again?

Not sure what you want. Below is the test case again. It is self-contained
for reproducing the crash bug (on Windows). Are you perhaps asking about the
define-minor-mode questions, or is this what you wanted?

-------------------8<----------------------------------

    -----Original Message-----
    From: Drew Adams [mailto:drew.adams@oracle.com]
    Sent: Monday, November 14, 2005 4:33 PM
    To: Emacs-Pretest-Bug
    Subject: weird defadvice bug with byte-compilation
    Importance: High


    This is a weird one. I've pared it down to the bare bones, I think -
    if I comment out any part of this, the bug doesn't occur. This
    obviously comes from a larger context - when it is pared down, the
    code doesn't make much sense, of course.

    If the stuff is in the same file, or the order is different, no bug
    (error). It must be like this: two files, one of which is compiled and
    required by the other. And the requiring file must have "compile" in
    its defadvice.

    Two files:

    File 1: foo.el
    --------------

    (defvar mymap nil "")

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))
      (push (cons 'my-mode mymap) minor-mode-map-alist))

    (defadvice next-history-element (after ffff activate) "" my-mode)

    (provide 'foo)

    File 2: bar.el
    --------------

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

    (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
    (setq load-path (append (list drews-lisp-dir) load-path))


    (defadvice occur-mode-goto-occurrence
      (around jjjjjj activate compile)
      ""
      ad-do-it)

    (require 'foo)

    Instructions:
    -------------

    1. emacs -q

    2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
       or 22). `C-x C-c'.

    3. emacs -q    (Emacs 22)

    4. Visit bar.el - don't load it.

    5. Select everything in bar.el except the (require 'foo), and
    do `eval-region'.

    6. Put the cursor just after the (require 'foo) and do `C-x
    C-e'. (Don't select it and do eval-region - that doesn't
    produce the bug!)

    You will get this error backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80)
    (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80)
    (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable
    `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable
    `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq
    ad-return-value (ad-Orig-next-history-element n)) my-mode
    ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq
    ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc:
    next-history-element$" (interactive "p") (let (ad-return-value)
    (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "???			\n
    \f
    \x0e\x0e??


    7. `C-x C-c'

    You will get a pop-up message with Yes/No buttons that says this:

    Emacs Abort Dialog

    "A fatal error has occurred! Would you like to attach a
    debugger? Select YES to debu, NO to abort Emacs"

    If you select Yes, you get a Window program exception and an
    invitation to send the details to Microsoft. The error report
    contents are these:

    Exception Information
    Code 0x80000003 Flags: 0x00000000
    Record: 0x0000000000000000 (didn't count 'em) Address:
    0x0000000077f75a58

    System Information
    Windows NT 5.1 Build: 2600
    CPU Vendor Code etc. blah blah blah

    Module 1
    emacs.exe
    blah blah

    Module 2
    ntdll.dll
    blah blah

    Module 3
    kernel32.dll
    blah blah

    Module 4
    msvcrt.dll
    blah blah

    etc. etc.

    ------------------------------------
    In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
     of 2005-06-26 on NONIQPC
    X server distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.3) --cflags
    -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
    -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
    -I../../zlib-1.2.2/include'

Re: [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation]

[Richard M. Stallman]

    Not sure what you want. Below is the test case again. It is self-contained
    for reproducing the crash bug (on Windows). Are you perhaps asking about the
    define-minor-mode questions, or is this what you wanted?

That is the test case I tested before.

     Are you perhaps asking about the
    define-minor-mode questions,

Yes--here's what I said:

	    Please see my previous emails, where I describe the
	    original case (which uses define-minor-mode).

	Could you send that test case again?

My response refers to "the original case".

RE: [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation]

[Drew Adams]

        Not sure what you want. Below is the test case again. It is
        self-contained for reproducing the crash bug (on Windows).
        Are you perhaps asking about the
        define-minor-mode questions, or is this what you wanted?

    That is the test case I tested before.

         Are you perhaps asking about the
        define-minor-mode questions,

    Yes--here's what I said:

    	    Please see my previous emails, where I describe the
    	    original case (which uses define-minor-mode).

    	Could you send that test case again?

    My response refers to "the original case".

I shouldn't have said "original case", but "original context". That is what
led to the misunderstanding. What you tested was the original case I
submitted. It contains everything needed for the crash bug.

What I was referring to was my original use context. You don't want all the
files I load (but I can point you to them, if you like). I described what I
did, but I will try to be clearer here. Let me know if this is what you want
or not.

1. I load files of mine with stuff like that shown in bar.el - just think of
this code as being in my .emacs.

2. I load a file of mine that does a defadvice like that seen in bar.el. It
has the `compile' keyword. There is no mention of variable `my-mode' or
foo.el in that file. To me, that defadvice should have no connection with
the problems seen, but if I don't do that defadvice the problem goes away.

3. I do (require 'foo) from a file I load (e.g. .emacs). foo.el has (provide
'foo).

4. In foo.el, I do, _in order_:

a. A defvar of a keymap variable, followed by code that defines keys in that
map and does (put ... 'menu-enable (and my-mode...)). This includes menu-bar
bindings for the (existing) Search menu.

b. A defadvice like the one shown in foo.el. It has _no_ `compile'. The body
refers to variable `my-mode'.

c. A define-minor-mode for mode `my-mode'.

d. This, at the very end (of foo.el): (if my-mode (my-mode 1)). I do that to
make sure that the mode-line lighter correctly corresponds to the mode state
(on/off).

5. Near the end of my .emacs (after loading foo.elc), I do this: (my-mode
1).

Here's my understanding of the "problems" (or misunderstanding on my part)
surrounding `define-minor-mode':

1. When foo.elc is loaded, it adds a binding to the menu-bar Search map, and
it adds a corresponding `menu-enable' that tests `my-mode'.

2. Then, loading foo.elc causes the defadvice in that file to be
byte-compiled. I do not understand why, since there is no `compile' in it.

3. That byte-compilation causes a warning to be displayed in buffer *Compile
Log*.

4. To display *Compile Log*, a new frame is created, because of the
special-display regexp.

5. When creating the new frame, the menu-bar Search menu is created for it,
and the `menu-enable' property with test `my-mode' is evaluated.

6. Since the `define-minor-mode' has not yet been evaluated during loading
of foo.elc, `my-mode' is still unbound when it is evaled for the Search
menu, so a backtrace is displayed with a void-variable error.

7. The backtrace is also a special-display buffer, so a new frame is created
to display it, provoking the same problem of step 5. Eli has explained the
ensuing crash bug on Windows.

If I don't use `define-minor-mode', I will naturally place a defcustom for
`my-mode' near the beginning of file foo.el. I was mistakenly expecting that
the automatic generation of the defcustom by `define-minor-mode' would also,
in effect, place it near the beginning of the byte-compiled file foo.elc.
Naive.

Now I understand that I must either place the `define-minor-mode' at the
file beginning or use an explicit defcustom (can I use a defcustom plus
`define-minor-mode' here, or will that provoke an error?). Actually, it is
sufficient to place the `define-minor-mode' before the defadvice in foo.el.

I still don't understand why the defadvice in foo.el, which has no
`compile', is byte-compiled on the fly. Nor do I understand why removing the
defadvice from bar.el (which has a `compile') causes the error to go away.
It's as if the `compile' from bar.el's defadvice were somehow transferred to
foo.el's defadvice, or the `compile' turned on a compile-advices-from-now-on
mode, so foo.el's defadvice was also compiled. I'm unclear on the way to use
defadvice, I guess.

I'm not claiming there is actually anything wrong (another bug). I'm just
confessing my confusion and naive expectations for `define-minor-mode'.
IIUC, we tell people to use the minor-mode function to set the minor-mode
variable, so that's what I do in .emacs. If I instead set the variable there
(setq), there is of course no unbound-variable error.

If there is a lesson here, besides my own learning, perhaps it is that we
could explain the use of `define-minor-mode' a bit better. And I wonder
about the behavior of the on-the-fly defadvice byte-compiling. Again, I'm no
doubt confused about that - I'd like to understand what's happening there
and why.

Does this help? If not, I'll be glad to point you to the source files.
They're all on Emacs Wiki.

Re: [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation]

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> And I wonder about the behavior of the on-the-fly defadvice
> byte-compiling. Again, I'm no doubt confused about that - I'd like
> to understand what's happening there and why.

See `ad-default-compilation-action'.

-- 
Johan Bockgård

RE: [drew.adams@oracle.com: RE:weirddefadvicebugwithbyte-compilation]

[Drew Adams]

    > And I wonder about the behavior of the on-the-fly defadvice
    > byte-compiling. Again, I'm no doubt confused about that - I'd like
    > to understand what's happening there and why.
    
    See `ad-default-compilation-action'.
    
Thanks very much. I never heard of that variable. Or, I may have read about it, but never paid adequate attention. Here is its doc string:

 Defines whether to compile advised definitions during activation.
 A value of `always' will result in unconditional compilation, `never' will
 always avoid compilation, `maybe' will compile if the byte-compiler is already
 loaded, and `like-original' will compile if the original definition of the
 advised function is compiled or a built-in function.  Every other value will
 be interpreted as `maybe'.  This variable will only be considered if the
 COMPILE argument of `ad-activate' was supplied as nil.

The default value is `maybe', and that's the value I had. The doc string says that that means that activation will also compile - if the byte-compiler is already loaded. I have no idea what loads the byte compiler, or why its being loaded would be the criterion applied here, but I must assume that in my case it was already loaded, and that that is the default situation (?). How to tell if it is loaded?

The doc string also says that this only happens if the COMPILE arg to ad-activate is nil. Well, I never explicitly called ad-activate, with or without a COMPILE arg - I used only defadvice. But I guess the `compile' FLAG for defadvice acts like the COMPILE arg to ad-activate in this regard (not mentioned in the doc string). Is that correct?

Does this all seem a bit convoluted to anyone besides me? Does anyone else think that, at the very least, the doc string of defadvice should clarify that the meaning of not using the `compile' flag can be overridden by the value of `ad-default-compilation-action' - depending on that variable's value, and that it will be overridden by the default value (`maybe') in the default configuration (byte-compiler loaded)?

What goes for the doc string of defadvice also goes for the description in Info (Elisp).

Apparently, the already elaborate description of defadvice in Info (node "Defining Advice") is far from being enough for someone to understand how to use defadvice in even a simple case.

RE: [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation]

[Drew Adams]

Sorry - sending again as plain text. My mail client sends formatted text
whenever I reply to a Unicode message.

------

        > And I wonder about the behavior of the on-the-fly defadvice
        > byte-compiling. Again, I'm no doubt confused about that - I'd like
        > to understand what's happening there and why.

        See `ad-default-compilation-action'.

    Thanks very much. I never heard of that variable. Or, I may
    have read about it, but never paid adequate attention. Here is
    its doc string:

      Defines whether to compile advised definitions during activation.
      A value of `always' will result in unconditional compilation,
      `never' will always avoid compilation, `maybe' will compile if the
      byte-compiler is already loaded, and `like-original' will compile
      if the original definition of the advised function is compiled or
      a built-in function.  Every other value will be interpreted as
      `maybe'.  This variable will only be considered if the
      COMPILE argument of `ad-activate' was supplied as nil.

    The default value is `maybe', and that's the value I had. The
    doc string says that that means that activation will also
    compile - if the byte-compiler is already loaded. I have no
    idea what loads the byte compiler, or why its being loaded
    would be the criterion applied here, but I must assume that in
    my case it was already loaded, and that that is the default
    situation (?). How to tell if it is loaded?

    The doc string also says that this only happens if the COMPILE
    arg to ad-activate is nil. Well, I never explicitly called
    ad-activate, with or without a COMPILE arg - I used only
    defadvice. But I guess the `compile' FLAG for defadvice acts
    like the COMPILE arg to ad-activate in this regard (not
    mentioned in the doc string). Is that correct?

    Does this all seem a bit convoluted to anyone besides me? Does
    anyone else think that, at the very least, the doc string of
    defadvice should clarify that the meaning of not using the
    `compile' flag can be overridden by the value of
    `ad-default-compilation-action' - depending on that variable's
    value, and that it will be overridden by the default value
    (`maybe') in the default configuration (byte-compiler loaded)?

    What goes for the doc string of defadvice also goes for the
    description in Info (Elisp).

    Apparently, the already elaborate description of defadvice in
    Info (node "Defining Advice") is far from being enough for
    someone to understand how to use defadvice in even a simple case.

Re: [drew.adams@oracle.com: RE:weirddefadvicebugwithbyte-compilation]

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

    [ad-default-compilation-action]

> The default value is `maybe', and that's the value I had. The doc
> string says that that means that activation will also compile - if
> the byte-compiler is already loaded. I have no idea what loads the
> byte compiler, or why its being loaded would be the criterion
> applied here, but I must assume that in my case it was already
> loaded, and that that is the default situation (?).

The byte-compiler is not loaded by default. The (defadvice ...
(... compile)...) in bar.el makes the difference.

> But I guess the `compile' FLAG for defadvice acts like the COMPILE
> arg to ad-activate in this regard (not mentioned in the doc string).
> Is that correct?

It seems so. 

-- 
Johan Bockgård

RE: [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation]

[Drew Adams]

        [ad-default-compilation-action]

    > The default value is `maybe', and that's the value I had. The doc
    > string says that that means that activation will also compile - if
    > the byte-compiler is already loaded. I have no idea what loads the
    > byte compiler, or why its being loaded would be the criterion
    > applied here, but I must assume that in my case it was already
    > loaded, and that that is the default situation (?).

    The byte-compiler is not loaded by default. The (defadvice ...
    (... compile)...) in bar.el makes the difference.

So, the presence of `compile' in one defadvice turns on byte-compilation for
subsequent defadvices - IOW, it's modal? I don't see that explained
anywhere.

    > But I guess the `compile' FLAG for defadvice acts like the COMPILE
    > arg to ad-activate in this regard (not mentioned in the doc string).
    > Is that correct?

    It seems so.

Does that COMPILE arg also turn on a byte-compilation mode that stays on
until turned off? That too is not documented, AFAICT.

Re: [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation]

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> So, the presence of `compile' in one defadvice turns on
> byte-compilation for subsequent defadvices - IOW, it's modal? I
> don't see that explained anywhere.

What part of "`maybe' will compile if the byte-compiler is already
loaded" don't you understand?

-- 
Johan Bockgård

RE: [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation]

[Drew Adams]

    > So, the presence of `compile' in one defadvice turns on
    > byte-compilation for subsequent defadvices - IOW, it's modal? I
    > don't see that explained anywhere.

    What part of "`maybe' will compile if the byte-compiler is already
    loaded" don't you understand?

Got it. Thanks again. It all comes back to `ad-default-compilation-action' -
the "explanation" of the defadvice `compile' flag behavior is the
description of option `ad-default-compilation-action' (3 long pages later,
with no forward xref to it). A few simple turns around Robinson's barn, and
we have it!

I think the doc string and the Info description of `defadvice' should
explicitly mention that the behavior of the `compile' FLAG value is
overridden by the value of `ad-default-compilation-action'. The current text
gives the impression that for a `defadvice' to be compiled you need both
defadvice flags present: `activate' and `compile'. And it gives the
impression that if both are present then the defadvice will be compiled.
Neither impression is necessarily correct, in fact - it all depends on
`ad-default-compilation-action'.

Also, given 1) this overriding behavior, 2) the default value of `maybe' for
`ad-default-compilation-action', and 3) the fact that a single `compile'
flag will turn on compilation modally, I don't see much sense in having that
flag.  __What is the use case for it?__

If the value of `ad-default-compilation-action' is `always', `never', or
`like-original' then the defadvice `compile' flag presumably does nothing
(it's presence or absence is irrelevant). If the option value is `maybe',
then the first occurrence of the `compile' flag in a defadvice turns
compilation on forever (until you change `ad-default-compilation-action').

That is, it would seem that the only time defadvice's `compile' has any
effect at all is for the first occurrence of the flag in some defadvice, and
then only if 1) flag `activate' is also present and 2)
`ad-default-compilation-action' is `maybe'. Is that right? Not much of a
raison d'etre.

I haven't tried the numerous possible combinations. I'm just trying to
understand the behavior from the descriptions. Summary: To me, the doc for
the defadvice `compile' flag conflicts with the doc for option
`ad-default-compilation-action', and it appears that the latter is what's
correct. And I don't really see why the `compile' flag exists.

I'm probably missing something here, as I was before by being ignorant of
`ad-default-compilation-action'. Let me know.

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

[Eli Zaretskii]

> Date: Fri, 09 Dec 2005 15:17:06 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
>     Lisp Backtrace:
>     "kill-emacs"
>     "save-buffers-kill-emacs"
>     "call-interactively"
>     "recursive-edit"
>     "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"
> 
> I will try to debug this when I have time (any ideas are welcome), but
> in the meantime, I see already that the problem that causes Emacs to
> commit suicide in frame #2 is that glyph_matrix_count is 8 instead of
> 0.  Here's the code of check_glyph_memory:
> 
>     /* Check glyph memory leaks.  This function is called from
>        shut_down_emacs.  Note that frames are not destroyed when Emacs
>        exits.  We therefore free all glyph memory for all active frames
>        explicitly and check that nothing is left allocated.  */
> 
>     void
>     check_glyph_memory ()
>     {
>       Lisp_Object tail, frame;
> 
>       /* Free glyph memory for all frames.  */
>       FOR_EACH_FRAME (tail, frame)
> 	free_glyphs (XFRAME (frame));
> 
>       /* Check that nothing is left allocated.  */
>       if (glyph_matrix_count)
> 	abort ();
>       if (glyph_pool_count)
> 	abort ();
>     }
> 
> It sounds like some frame's glyph matrices were not freed for some
> reason?

I did some debugging.  I do not yet have all the answers, but the fog
is beginning to clear.

First, I think that a Unix or GNU/Linux build on X, but without any
toolkits (no GTK, no Motif/Lesstiff, no Xt), might hit this bug as
well.  Can someone please try that?  I cannot easily build and test
such a version on GNU boxes to which I have access.

Second, the crash is somehow related to the fact that x-create-frame
is called from within itself, or something like that: When advice
byte-compiles the advised function on the fly, it hits the problem
with the unbound variable, and wants to display a warning in the
*Compile-Log* buffer.  However, due to this line from bar.el:

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

*Compile-Log* is one of the buffers that need a separate frame, so
Emacs begins to create a frame.  During that frame's creation, it
hits the problem with the void variable again, and wants to display
the backtrace, but the *Backtrace* buffer also needs a separate
frame...

Here's the relevant portion of the Lisp backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)

When the frame displaying *Backtrace* pops up, the variable
Vframe_list does not yet include the frame that was partly created to
display *Compile-Log*, so check_glyph_memory does not free that
frame's glyph matrices.

Does this make sense?

RE: [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation]

[Drew Adams]

    Does this make sense?

It does, as far as I can tell. I don't understand all of it, however, I
admit. I still don't understand, for instance:

1. why byte-compiling the defadvice in bar.el would eval my-mode (my-mode
does not even appear in bar.el)

2. why evaling the defadvice in foo.el would eval my-mode (the BODY of
defadvice is not supposed to be quoted)

3. what the interaction is between the two defadvice's in the two files, and
how they relate to byte-compiling

4. how to use define-minor-mode in connection with the menu-enable keymap
stuff

5. why selecting (require 'foo) and doing eval-region does not manifest the
bug, but putting the cursor after (require 'foo) and doing `C-x C-e' does
manifest the bug.

Wrt #3, only the defadvice in bar.el has `compile', and that defadvice evals
without error. It is when you eval the (require 'foo) that the unbound error
occurs. Also, neither advised function is actually called.

Wrt #4, the original context uses define-minor-mode to define variable
my-mode. I also forgot to mention that I turn on the minor mode in my .emacs
(by calling the my-mode function), before loading the libraries in question,
and the library that corresponds to foo.el does this at the end:

 ;; Apparently, this is needed if the initial value is non-nil.
 ;; Otherwise, the lighter shows the mode as on, but it is not on.
 (if my-mode (my-mode 1))

----

BTW (doc bug?) -

The doc string for defadvice does not really explain what BODY is for - it
says only this: "Any s-expression". Neither the doc string nor the Info
explanation of BODY-FORMS explains that it should not be quoted (it is not
evaled by defadvice). I would expect both doc string and Info to make
reference to the body forms when describing the overall effect and perhaps
also when describing the other individual args.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 11 Dec 2005 13:35:46 -0800
> 
>     Does this make sense?
> 
> It does, as far as I can tell. I don't understand all of it, however, I
> admit. I still don't understand, for instance:
> 
> 1. why byte-compiling the defadvice in bar.el would eval my-mode (my-mode
> does not even appear in bar.el)

I think it doesn't eval it, it just sees that my-mode is not bound.
The warning says "reference to free variable `my-mode'", see the
backtrace.  This is a standard warning from the byte compiler, it is
meant to help you detect typos in variable names.

> 2. why evaling the defadvice in foo.el would eval my-mode (the BODY of
> defadvice is not supposed to be quoted)

Because defadvice byte-compiles the function it creates on the fly, I
guess.

> 5. why selecting (require 'foo) and doing eval-region does not manifest the
> bug, but putting the cursor after (require 'foo) and doing `C-x C-e' does
> manifest the bug.

Because, by default, eval-expression-debug-on-error is t, and it
affects C-x C-e.  If I set eval-expression-debug-on-error to nil,
Emacs behaves with C-x C-e like it does with eval-region: it doesn't
pop up the *Backtrace* buffer in a separate frame, and the bug doesn't
happen.

RE: [drew.adams@oracle.com: RE: weird defadvice bugwithbyte-compilation]

[Drew Adams]

    > It does, as far as I can tell. I don't understand all of it,
    > however, I admit. I still don't understand, for instance:
    >
    > 1. why byte-compiling the defadvice in bar.el would eval
    >    my-mode (my-mode does not even appear in bar.el)

    I think it doesn't eval it, it just sees that my-mode is not bound.
    The warning says "reference to free variable `my-mode'", see the
    backtrace.  This is a standard warning from the byte compiler, it is
    meant to help you detect typos in variable names.

OK. I was confused because it was the byte-compilation that led ultimately
to x-create-frame raising an unbound var error.

    > 2. why evaling the defadvice in foo.el would eval my-mode (the BODY of
    >    defadvice is not supposed to be quoted)

    Because defadvice byte-compiles the function it creates on the fly, I
    guess.

But it is only the defadvice in bar.el, not the defadvice in foo.el, that
has the keyword `compile'.

And even if it does byte-compile foo.el on the fly (for whatever reason),
why would it eval my-mode - the body of a defadvice is not supposed to need
to be quoted (it is not evaled by defadvice).

That is, I don't understand why a byte-compiler warning of a potentially
unbound variable would lead to a *Backtrace* being created - a warning is
not an error, and even byte-compiler errors (as opposed to warnings) do not
result in a *Backtrace*.

    > 5. why selecting (require 'foo) and doing eval-region does
    >    not manifest the bug, but putting the cursor after
    >   (require 'foo) and doing `C-x C-e' does manifest the bug.

    Because, by default, eval-expression-debug-on-error is t, and it
    affects C-x C-e.  If I set eval-expression-debug-on-error to nil,
    Emacs behaves with C-x C-e like it does with eval-region: it doesn't
    pop up the *Backtrace* buffer in a separate frame, and the bug doesn't
    happen.

Ah - thanks. That makes sense, given your explanation of the bug being
manifested in x-create-frame.

I don't understand, however, your statement that when the byte compiler
tries to display special-buffer *Compile Log* in a separate frame "it hits
the problem with the void variable again". What is the "problem with the
void variable"? For the byte-compiler it was only a question of displaying a
warning, there was no error to be raised. Why would display of *Compile Log*
in a separate frame raise an unbound-variable error?

RE: [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation]

[Drew Adams]

        > It does, as far as I can tell. I don't understand all of it,
        > however, I admit. I still don't understand, for instance:
        >
        > 1. why byte-compiling the defadvice in bar.el would eval
        >    my-mode (my-mode does not even appear in bar.el)

        I think it doesn't eval it, it just sees that my-mode is not bound.
        The warning says "reference to free variable `my-mode'", see the
        backtrace.  This is a standard warning from the byte compiler, it is
        meant to help you detect typos in variable names.

    OK. I was confused because it was the byte-compilation that led
    ultimately to x-create-frame raising an unbound var error.

        > 2. why evaling the defadvice in foo.el would eval my-mode
        >    (the BODY of defadvice is not supposed to be quoted)

        Because defadvice byte-compiles the function it creates on
        the fly, I guess.

    But it is only the defadvice in bar.el, not the defadvice in
    foo.el, that has the keyword `compile'.

    And even if it does byte-compile foo.el on the fly (for
    whatever reason), why would it eval my-mode - the body of a
    defadvice is not supposed to need
    to be quoted (it is not evaled by defadvice).

    That is, I don't understand why a byte-compiler warning of a potentially
    unbound variable would lead to a *Backtrace* being created - a
    warning is not an error, and even byte-compiler errors (as opposed to
    warnings) do not result in a *Backtrace*.

        > 5. why selecting (require 'foo) and doing eval-region does
        >    not manifest the bug, but putting the cursor after
        >   (require 'foo) and doing `C-x C-e' does manifest the bug.

        Because, by default, eval-expression-debug-on-error is t, and it
        affects C-x C-e.  If I set eval-expression-debug-on-error to nil,
        Emacs behaves with C-x C-e like it does with eval-region: it doesn't
        pop up the *Backtrace* buffer in a separate frame, and the
        bug doesn't happen.

    Ah - thanks. That makes sense, given your explanation of the bug being
    manifested in x-create-frame.

    I don't understand, however, your statement that when the byte compiler
    tries to display special-buffer *Compile Log* in a separate
    frame "it hits
    the problem with the void variable again". What is the "problem with the
    void variable"? For the byte-compiler it was only a question of
    displaying a
    warning, there was no error to be raised. Why would display of
    *Compile Log*
    in a separate frame raise an unbound-variable error?

Nevermind; I understand now what happened (wrt the unbound var, not the
crash bug). I was confused about who was raising the unbound var error, but
I see now that x-create-frame was doing so because the menu-enable property
evaled it for a menu-bar menu when x-create-frame tried to create the
*Compile Log* frame (which has a menu-bar).

This makes me wonder now if byte-compiling in defadvice (i.e. on the fly)
should display a *Compile Log* buffer at all. I don't know. In any case,
that's clearly the cause of the problem here (but not the explanation of the
crash bug).

I still have a question, however, about how best to use define-minor-mode to
define the mode variable so that it can be used in a put 'menu-enable. Is it
necessary to do the define-minor-mode before doing the put? I guess so; but
in that case, I prefer the old method of defining a minor-mode function and
its variable (defcustom) separately. The problem is the same, but I always
place variable definitions at the top, and such a defcustom would be defined
before the  variable was used in the put 'menu-enable. In the new system, I
was calling the minor-mode function first thing (in .emacs), to set the
variable, but that function couldn't be called until its defining library
was loaded, and that meant that the variable wasn't defined when the
*Compile Log* was displayed when byte-compiling a defadvice in the file.

Moral (for me): Either don't use define-minor-mode at all or use it first
thing in a file, before you make any references (even quoted references,
like here) to its mode variable.

Thanks for helping me understand, and good luck with the crash bug. - Drew

Re: [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 11 Dec 2005 22:44:15 -0800
> 
> Nevermind; I understand now what happened (wrt the unbound var, not the
> crash bug). I was confused about who was raising the unbound var error, but
> I see now that x-create-frame was doing so because the menu-enable property
> evaled it for a menu-bar menu when x-create-frame tried to create the
> *Compile Log* frame (which has a menu-bar).

Exactly.

> This makes me wonder now if byte-compiling in defadvice (i.e. on the fly)
> should display a *Compile Log* buffer at all. I don't know.

Why not?  It's a byte compilation like any other one, and these
warnings do serve a purpose: your code, as posted, had a bug.

> In any case, that's clearly the cause of the problem here (but not
> the explanation of the crash bug).

The explanation of the crash is that, because the *Backtrace* buffer
is displayed in its own separate frame, and that separate frame is
created in the middle of the process of creating the *Compile-Log*'s
frame's menu, Emacs somehow fails to record the *Backtrace* frame in
the list of live frames.  And then, when Emacs is killed, the function
check_glyph_memory, which walks the frame list and releases all the
glyph matrices it finds in each frame, misses that one frame which is
not recorded in the list of frames.

Can someone please try reproducing this in a non-toolkit X build?  I
think that build might have the same problem as the MS-Windows build.

> I still have a question, however, about how best to use define-minor-mode to
> define the mode variable so that it can be used in a put 'menu-enable. Is it
> necessary to do the define-minor-mode before doing the put? I guess so; but
> in that case, I prefer the old method of defining a minor-mode function and
> its variable (defcustom) separately. The problem is the same, but I always
> place variable definitions at the top, and such a defcustom would be defined
> before the  variable was used in the put 'menu-enable. In the new system, I
> was calling the minor-mode function first thing (in .emacs), to set the
> variable, but that function couldn't be called until its defining library
> was loaded, and that meant that the variable wasn't defined when the
> *Compile Log* was displayed when byte-compiling a defadvice in the file.

Sorry, I'm not an expert on minor modes.  Anyone?

RE: [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation]

[Drew Adams]

    > This makes me wonder now if byte-compiling in defadvice (i.e.
    > on the fly)
    > should display a *Compile Log* buffer at all. I don't know.

    Why not?  It's a byte compilation like any other one, and these
    warnings do serve a purpose: your code, as posted, had a bug.

Where is the bug? The byte-compiler warning presumably arose because it
compiled a defadvice that referred to variable my-mode. That variable is not
bound in the defadvice body and it might not be bound at the point in the
file when the defadvice is compiled. Is that a bug? It is only a warning, so
I don't really mind, but I don't see how the code is bugged. Should people
systematically place defadvice last in a file or do (provide 'x)(require 'x)
just to make sure that all variables in a defadvice body are defined before
it is compiled?

    > In any case, that's clearly the cause of the problem here (but not
    > the explanation of the crash bug).

    The explanation of the crash is that, because the *Backtrace* buffer
    is displayed in its own separate frame, and that separate frame is
    created in the middle of the process of creating the *Compile-Log*'s
    frame's menu, Emacs somehow fails to record the *Backtrace* frame in
    the list of live frames.  And then, when Emacs is killed, the function
    check_glyph_memory, which walks the frame list and releases all the
    glyph matrices it finds in each frame, misses that one frame which is
    not recorded in the list of frames.

Thanks.

    Can someone please try reproducing this in a non-toolkit X build?  I
    think that build might have the same problem as the MS-Windows build.

    > I still have a question, however, about how best to use
    > define-minor-mode to define the mode variable so that it can be
    > used in a put 'menu-enable. Is it necessary to do the
    > define-minor-mode before doing the put? I guess so; but
    > in that case, I prefer the old method of defining a
    > minor-mode function and its variable (defcustom) separately.
    > The problem is the same, but I always place variable definitions
    > at the top, and such a defcustom would be defined before the
    > variable was used in the put 'menu-enable. In the new system, I
    > was calling the minor-mode function first thing (in .emacs),
    > to set the variable, but that function couldn't be called until
    > its defining library was loaded, and that meant that the
    > variable wasn't defined when the *Compile Log* was displayed
    > when byte-compiling a defadvice in the file.

    Sorry, I'm not an expert on minor modes.  Anyone?

I also don't understand, as I mentioned, _why_ the defadvice in foo.el is
byte-compiled - it has no `compile' keyword. Only the defadvice in bar.el
has `compile', and it does not refer to variable my-mode. If the defadvice
in bar.el is removed, the bug is not manifested, presumably because the
defadvice in foo.el is not byte-compiled. I don't see why a `compile' in a
defadvice in one file would cause compilation of a defadvice in another
file. Is that normal?

Re: [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 12 Dec 2005 13:53:31 -0800
> 
>     > This makes me wonder now if byte-compiling in defadvice (i.e.
>     > on the fly)
>     > should display a *Compile Log* buffer at all. I don't know.
> 
>     Why not?  It's a byte compilation like any other one, and these
>     warnings do serve a purpose: your code, as posted, had a bug.
> 
> Where is the bug? The byte-compiler warning presumably arose because it
> compiled a defadvice that referred to variable my-mode. That variable is not
> bound in the defadvice body and it might not be bound at the point in the
> file when the defadvice is compiled. Is that a bug?

Well, it might be.  (I thought you actually said elsewhere in this
thread that it was a bug, and that you deliberately kept it in the
code to reproduce the crash.)  The warning alerts you to look into
this.

> Should people systematically place defadvice last in a file or do
> (provide 'x)(require 'x) just to make sure that all variables in a
> defadvice body are defined before it is compiled?

If you want the byte compiler help you find such typos, then yes, you
should try to eliminate gratuitous warnings, to keep the noise level
low enough for you to see the real warnings.

> I also don't understand, as I mentioned, _why_ the defadvice in foo.el is
> byte-compiled - it has no `compile' keyword.

I thought this was how defadvice worked, but I might be wrong.  In any
case, the fact that the byte compiler is run is clear from the
backtrace.

RE: [drew.adams@oracle.com: RE:weirddefadvicebugwithbyte-compilation]

[Drew Adams]

    > Where is the bug? The byte-compiler warning presumably arose
    > because it compiled a defadvice that referred to variable my-mode.
    > That variable is not bound in the defadvice body and it might
    > not be bound at the point in the
    > file when the defadvice is compiled. Is that a bug?

    (I thought you actually said elsewhere in this
    thread that it was a bug, and that you deliberately kept it in the
    code to reproduce the crash.)

No. At one point I mistakenly thought that the byte-compilation was evaling
the variable. I was surprised that the quoted unbound variable was evaled
(it was the frame creation that tried to check a menu-enable property and
evaled the variable).

Also, I expected define-minor-mode to somehow DTRT, defining the mode
variable first thing when the file was loaded, but I guess it doesn't do
that. Users are, I believe, told to turn on a minor mode by using the mode
toggle function, not by setting the mode variable. But if you do that in a
case like this (as I did, in my .emacs), you can get an unbound-variable
error like this. I suspect it is common to use a minor-mode var in a
menu-bar menu-enable property, though it is probably uncommon to do so for
an existing menu-bar menu (e.g. Search), rather than a menu specific to the
mode.

    > Should people systematically place defadvice last in a file or do
    > (provide 'x)(require 'x) just to make sure that all variables in a
    > defadvice body are defined before it is compiled?

    If you want the byte compiler help you find such typos, then yes, you
    should try to eliminate gratuitous warnings, to keep the noise level
    low enough for you to see the real warnings.

    > I also don't understand, as I mentioned, _why_ the defadvice
    > in foo.el is byte-compiled - it has no `compile' keyword.

    I thought this was how defadvice worked, but I might be wrong.  In any
    case, the fact that the byte compiler is run is clear from the
    backtrace.

That it would be run for bar.el, whose defadvice has the keyword `compile',
I understand. That it would be run for foo.el, whose defadvice has no
`compile', I do not understand. Is that how defadvice works? Can someone
clear this up?

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

[Richard M. Stallman]

    Second, the crash is somehow related to the fact that x-create-frame
    is called from within itself, or something like that:

Very interesting.  Can you send me the C backtrace?  That's what
matters here.

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

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 12 Dec 2005 00:23:33 -0500
> 
>     Second, the crash is somehow related to the fact that x-create-frame
>     is called from within itself, or something like that:
> 
> Very interesting.  Can you send me the C backtrace?  That's what
> matters here.

I posted the C backtrace in this thread.  Here is a more full version:

    Program received signal SIGTRAP, Trace/breakpoint trap.
    [Switching to thread 2924.0x948]
    0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
    (gdb) bt 40
    #0  0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
    #1  0x011319c7 in w32_abort () at w32fns.c:8953
    #2  0x01084cee in check_glyph_memory () at dispnew.c:2583
    #3  0x010018c3 in shut_down_emacs (sig=0, no_x=0, stuff=23861249)
	at emacs.c:2170
    #4  0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2075
    #5  0x0100c5da in Ffuncall (nargs=1, args=0x82c1b0) at eval.c:2879
    #6  0x011094f9 in Fbyte_code (bytestr=18486379, vector=18486500, maxdepth=40)
	at bytecode.c:694
    #7  0x0100bfae in funcall_lambda (fun=18486332, nargs=1, arg_vector=0x82c374)
	at eval.c:3066
    #8  0x0100c3a1 in Ffuncall (nargs=2, args=0x82c370) at eval.c:2934
    #9  0x01107858 in Fcall_interactively (function=24463457,
	record_flag=23861249, keys=23920644) at callint.c:884
    #10 0x0104ca3e in Fcommand_execute (cmd=24463457, record_flag=23861249,
	keys=23861249, special=23861249) at keyboard.c:9751
    #11 0x01053279 in command_loop_1 () at keyboard.c:1780
    #12 0x0100a81b in internal_condition_case (bfun=0x1052f39 <command_loop_1>,
	handlers=23925361, hfun=0x104d397 <cmd_error>) at eval.c:1465
    #13 0x010479b7 in command_loop_2 () at keyboard.c:1318
    #14 0x0100a750 in internal_catch (tag=23949793,
	func=0x1047994 <command_loop_2>, arg=23861249) at eval.c:1211
    #15 0x0104777f in command_loop () at keyboard.c:1285
    #16 0x01047867 in recursive_edit_1 () at keyboard.c:990
    #17 0x0104797d in Frecursive_edit () at keyboard.c:1051
    #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876
    #19 0x011094f9 in Fbyte_code (bytestr=26968867, vector=27021828, maxdepth=32)
	at bytecode.c:694
    #20 0x0100baf6 in Feval (form=26208213) at eval.c:2225
    #21 0x0100bdc3 in Fprogn (args=26207965) at eval.c:432
    #22 0x0109cbaa in Fsave_window_excursion (args=26207965) at window.c:6368
    #23 0x01109ef2 in Fbyte_code (bytestr=26969027, vector=29856260, maxdepth=224)
	at bytecode.c:855
    #24 0x0100bfae in funcall_lambda (fun=29723972, nargs=2, arg_vector=0x82cbd4)
	at eval.c:3066
    #25 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934
    #26 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371
    #27 0x0100d9c1 in apply1 (fn=24109177, arg=26176261) at eval.c:2632
    #28 0x0100b270 in call_debugger (arg=26176261) at eval.c:289
    #29 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045,
	sig=23925529, data=26176285, debugger_value_ptr=0x82cce8) at eval.c:1815
    #30 0x0100c93a in Fsignal (error_symbol=23925529, data=26176285) at eval.c:1642
    #31 0x01005ad2 in Fsymbol_value (symbol=29457225) at data.c:1143
    #32 0x0100b84c in Feval (form=29457225) at eval.c:2105
    #33 0x0100e1d4 in Fand (args=25815637) at eval.c:353
    #34 0x0100bbdb in Feval (form=25815653) at eval.c:2166
    #35 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>,
	arg=25815653, handlers=23925361,
	hfun=0x104b17c <menu_item_eval_property_1>) at eval.c:1506
    #36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
    #37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
	at keyboard.c:7380
    #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...)

    Lisp Backtrace:
    "kill-emacs"
    "save-buffers-kill-emacs"
    "call-interactively"
    "recursive-edit"
    "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"
    0x1d22e84 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"
    (gdb)

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

[Richard M. Stallman]

	#36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
	#37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
	    at keyboard.c:7380
	#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!

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

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 12 Dec 2005 22:14:53 -0500
> 
> 	#36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
> 	#37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
> 	    at keyboard.c:7380
> 	#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.

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

[Richard M. Stallman]

    > 	#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.

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

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> 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.

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

[Richard M. Stallman]

    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.

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

[Eli Zaretskii]

> 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.

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

[Richard M. Stallman]

    > 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.

In that case, with a breakpoint at x_y_to_hpos_vpos
do you see more stack trace info?

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

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Thu, 15 Dec 2005 20:51:15 -0500
> 
> In that case, with a breakpoint at x_y_to_hpos_vpos
> do you see more stack trace info?

It was not that easy (needed to find the correct sequence of `step',
`finish', and `next' commands to get the info), but the results are
below.  As you see, menu_item_eval_property, which is called as part
of building the menu items, causes Feval to be called, which then
enters the debugger, which in turn causes another frame to be created
in the middle of creating the frame for *Compile-Log*.

  #0  new_glyph_matrix (pool=0x0) at dispnew.c:523
  #1  0x01084400 in allocate_matrices_for_window_redisplay (w=0x1d77e00)
      at dispnew.c:2052
  #2  0x010846b5 in adjust_frame_glyphs (f=0x1d77000) at dispnew.c:2380
  #3  0x01084a94 in adjust_glyphs (f=0x1d77000) at dispnew.c:2081
  #4  0x010d910b in x_set_frame_parameters (f=0x1d77000, alist=30471261)
      at frame.c:2780
  #5  0x010dab97 in x_default_parameter (f=0x1d77000, alist=30471949,
      prop=24041361, deflt=8, xprop=0x12b4870 "menuBar",
      xclass=0x12b4868 "MenuBar", type=RES_TYPE_NUMBER) at frame.c:3635
  #6  0x01137e16 in Fx_create_frame (parameters=30471949) at w32fns.c:4275
  #7  0x0100c5da in Ffuncall (nargs=2, args=0x82c3b8) at eval.c:2879
  #8  0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40)
      at bytecode.c:694
  #9  0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82c504)
      at eval.c:3066
  #10 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c500) at eval.c:2934
  #11 0x011095d9 in Fbyte_code (bytestr=18940947, vector=18940988, maxdepth=24)
      at bytecode.c:694
  #12 0x0100bfae in funcall_lambda (fun=18940900, nargs=1, arg_vector=0x82c644)
      at eval.c:3066
  #13 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c640) at eval.c:2934
  #14 0x011095d9 in Fbyte_code (bytestr=18935771, vector=18935916, maxdepth=40)
      at bytecode.c:694
  #15 0x0100bfae in funcall_lambda (fun=18935716, nargs=1, arg_vector=0x82c79c)
      at eval.c:3066
  #16 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c798) at eval.c:2934
  #17 0x0100d4ef in call1 (fn=26425137, arg1=30856708) at eval.c:2664
  #18 0x0106288f in Fpop_to_buffer (buffer=30856708, other_window=23861249,
      norecord=23861249) at buffer.c:1726
  #19 0x0100c5b3 in Ffuncall (nargs=2, args=0x82c880) at eval.c:2885
  #20 0x011095d9 in Fbyte_code (bytestr=30877059, vector=26801924, maxdepth=32)
      at bytecode.c:694
  #21 0x0100baf6 in Feval (form=30363701) at eval.c:2225
  #22 0x0100bdc3 in Fprogn (args=30363477) at eval.c:432
  #23 0x0109cc0a in Fsave_window_excursion (args=30363477) at window.c:6368
  #24 0x01109fd2 in Fbyte_code (bytestr=30876899, vector=30855684, maxdepth=224)
      at bytecode.c:855
  #25 0x0100bfae in funcall_lambda (fun=30392004, nargs=2, arg_vector=0x82cbd4)
      at eval.c:3066
  #26 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934
  #27 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371
  #28 0x0100d9c1 in apply1 (fn=24109177, arg=30366645) at eval.c:2632
  #29 0x0100b270 in call_debugger (arg=30366645) at eval.c:289
  #30 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045,
      sig=23925529, data=30366677, debugger_value_ptr=0x82cce8) at eval.c:1815
  #31 0x0100c93a in Fsignal (error_symbol=23925529, data=30366677) at eval.c:1642
  #32 0x01005ad2 in Fsymbol_value (symbol=29501537) at data.c:1143
  #33 0x0100b84c in Feval (form=29501537) at eval.c:2105
  #34 0x0100e1d4 in Fand (args=25851101) at eval.c:353
  #35 0x0100bbdb in Feval (form=25851109) at eval.c:2166
  #36 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>,
      arg=25851109, handlers=23925361,
      hfun=0x104b18c <menu_item_eval_property_1>) at eval.c:1506
  #37 0x0104b216 in menu_item_eval_property (sexpr=25851109) at keyboard.c:7193
  #38 0x0104b6b1 in parse_menu_item (item=25851149, notreal=0, inmenubar=0)
      at keyboard.c:7380
  #39 0x0112ae23 in single_menu_item (key=29501585, item=0,
      pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
  #40 0x0112b10e in single_keymap_panes (keymap=29501585, pane_name=0, prefix=9,
      notreal=17085553, maxdepth=24812205) at w32menu.c:468
  #41 parse_single_submenu (item_key, item_name, maps) at w32menu.c:1499
  #42 set_frame_menubar (f=0x16ca400, first_time=1, deep_p=1) at w32menu.c:1406
  #43 0x0112c4f8 in initialize_frame_menubar () at w32menu.c:1666
  #44 0x0113863a in Fx_create_frame (parameters=25605765) at w32fns.c:3951
  #45 0x0100c5da in Ffuncall (nargs=2, args=0x82d728) at eval.c:2879
  #46 0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40)
      at bytecode.c:694
  #47 0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82d874)
      at eval.c:3066
  #48 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d870) at eval.c:2934
  #49 0x011095d9 in Fbyte_code (bytestr=18940883, vector=18940924, maxdepth=24)
      at bytecode.c:694
  #50 0x0100bfae in funcall_lambda (fun=18940836, nargs=1, arg_vector=0x82d9b4)
      at eval.c:3066
  #51 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d9b0) at eval.c:2934
  #52 0x011095d9 in Fbyte_code (bytestr=18935707, vector=18935852, maxdepth=40)
      at bytecode.c:694
  #53 0x0100bfae in funcall_lambda (fun=18935652, nargs=1, arg_vector=0x82db0c)
      at eval.c:3066
  #54 0x0100c3a1 in Ffuncall (nargs=2, args=0x82db08) at eval.c:2934
  #55 0x0100d4ef in call1 (fn=26426113, arg1=23898116) at eval.c:2664
  #56 0x0100c5b3 in Ffuncall (nargs=2, args=0x82dbd0) at eval.c:2885
  #57 0x011095d9 in Fbyte_code (bytestr=29441059, vector=30482180, maxdepth=48)
      at bytecode.c:694
  #58 0x0100bfae in funcall_lambda (fun=26442500, nargs=4, arg_vector=0x82dd24)
      at eval.c:3066
  #59 0x0100c3a1 in Ffuncall (nargs=5, args=0x82dd20) at eval.c:2934
  #60 0x011095d9 in Fbyte_code (bytestr=29697891, vector=30697668, maxdepth=40)
      at bytecode.c:694
  #61 0x0100bfae in funcall_lambda (fun=30763684, nargs=3, arg_vector=0x82de74)
      at eval.c:3066
  #62 0x0100c3a1 in Ffuncall (nargs=4, args=0x82de70) at eval.c:2934
  #63 0x011095d9 in Fbyte_code (bytestr=29697715, vector=30697604, maxdepth=32)
      at bytecode.c:694
  #64 0x0100bfae in funcall_lambda (fun=30763524, nargs=2, arg_vector=0x82dfb4)
      at eval.c:3066
  #65 0x0100c3a1 in Ffuncall (nargs=3, args=0x82dfb0) at eval.c:2934
  #66 0x011095d9 in Fbyte_code (bytestr=29622083, vector=30771204, maxdepth=64)
      at bytecode.c:694
  #67 0x0100bfae in funcall_lambda (fun=30781956, nargs=2, arg_vector=0x82e104)
      at eval.c:3066
  #68 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e100) at eval.c:2934
  #69 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32)
      at bytecode.c:694
  #70 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e244)
      at eval.c:3066
  #71 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e240) at eval.c:2934
  #72 0x011095d9 in Fbyte_code (bytestr=30831027, vector=30817284, maxdepth=32)
      at bytecode.c:694
  #73 0x0100bfae in funcall_lambda (fun=30817156, nargs=2, arg_vector=0x82e384)
      at eval.c:3066
  #74 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e380) at eval.c:2934
  #75 0x011095d9 in Fbyte_code (bytestr=30867779, vector=30821892, maxdepth=32)
      at bytecode.c:694
  #76 0x0100bfae in funcall_lambda (fun=30826180, nargs=1, arg_vector=0x82e4c4)
      at eval.c:3066
  #77 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e4c0) at eval.c:2934
  #78 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32)
      at bytecode.c:694
  #79 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e604)
      at eval.c:3066
  #80 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e600) at eval.c:2934
  #81 0x011095d9 in Fbyte_code (bytestr=29621795, vector=30704260, maxdepth=56)
      at bytecode.c:694
  #82 0x0100bfae in funcall_lambda (fun=30782820, nargs=3, arg_vector=0x82e754)
      at eval.c:3066
  #83 0x0100c3a1 in Ffuncall (nargs=4, args=0x82e750) at eval.c:2934
  #84 0x011095d9 in Fbyte_code (bytestr=29621651, vector=30771972, maxdepth=64)
      at bytecode.c:694
  #85 0x0100bfae in funcall_lambda (fun=30783140, nargs=1, arg_vector=0x82e8a4)
      at eval.c:3066
  #86 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e8a0) at eval.c:2934
  #87 0x011095d9 in Fbyte_code (bytestr=29621395, vector=30705028, maxdepth=112)
      at bytecode.c:694
  #88 0x0100bfae in funcall_lambda (fun=30784260, nargs=0, arg_vector=0x82ea24)
      at eval.c:3066
  #89 0x0100c3a1 in Ffuncall (nargs=1, args=0x82ea20) at eval.c:2934
  #90 0x0100bb14 in Feval (form=29790573) at eval.c:2222
  #91 0x0100dca3 in internal_lisp_condition_case (var=29436577,
      bodyform=29790573, handlers=26199045) at eval.c:1412
  #92 0x01109f4b in Fbyte_code (bytestr=29621379, vector=30704900, maxdepth=24)
      at bytecode.c:884
  #93 0x0100bfae in funcall_lambda (fun=30784100, nargs=1, arg_vector=0x82ecf4)
      at eval.c:3066
  #94 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ecf0) at eval.c:2934
  #95 0x011095d9 in Fbyte_code (bytestr=30868643, vector=28317700, maxdepth=24)
      at bytecode.c:694
  #96 0x0100bfae in funcall_lambda (fun=26665668, nargs=1, arg_vector=0x82ee34)
      at eval.c:3066
  #97 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ee30) at eval.c:2934
  #98 0x011095d9 in Fbyte_code (bytestr=29493683, vector=30699204, maxdepth=56)
      at bytecode.c:694
  #99 0x0100bfae in funcall_lambda (fun=30701988, nargs=2, arg_vector=0x82ef84)
      at eval.c:3066
  #100 0x0100c3a1 in Ffuncall (nargs=3, args=0x82ef80) at eval.c:2934
  #101 0x011095d9 in Fbyte_code (bytestr=29493507, vector=30707332, maxdepth=32)
      at bytecode.c:694
  #102 0x0100bfae in funcall_lambda (fun=30701668, nargs=2, arg_vector=0x82f0c4)
      at eval.c:3066
  #103 0x0100c3a1 in Ffuncall (nargs=3, args=0x82f0c0) at eval.c:2934
  #104 0x011095d9 in Fbyte_code (bytestr=24006403, vector=24559876, maxdepth=40)
      at bytecode.c:694
  #105 0x0100baf6 in Feval (form=25931277) at eval.c:2225
  #106 0x0106a837 in readevalloop (readcharfun=23946201, stream=0x77c5fce0,
      sourcename=24464883, evalfun=0x100b5de <Feval>, printflag=0,
      unibyte=23861249, readfun=23861249, start=23861249, end=23861249)
      at lread.c:1406
  #107 0x0106b404 in Fload (file=26699395, noerror=23861249, nomessage=23861297,
      nosuffix=23861249, must_suffix=23861297) at lread.c:920
  #108 0x01078293 in Frequire (feature=29485993, filename=23861249,
      noerror=23861249) at fns.c:3618
  #109 0x0100baf6 in Feval (form=25932213) at eval.c:2225
  #110 0x0100c5da in Ffuncall (nargs=2, args=0x82f780) at eval.c:2879
  #111 0x011095d9 in Fbyte_code (bytestr=19176851, vector=19177028, maxdepth=64)
      at bytecode.c:694
  #112 0x0100bfae in funcall_lambda (fun=19176812, nargs=1, arg_vector=0x82f8d4)
      at eval.c:3066
  #113 0x0100c3a1 in Ffuncall (nargs=2, args=0x82f8d0) at eval.c:2934
  #114 0x011095d9 in Fbyte_code (bytestr=19177683, vector=19177740, maxdepth=32)
      at bytecode.c:694
  #115 0x0100bfae in funcall_lambda (fun=19177644, nargs=1, arg_vector=0x82fa84)
      at eval.c:3066
  #116 0x0100c3a1 in Ffuncall (nargs=2, args=0x82fa80) at eval.c:2934
  #117 0x01107938 in Fcall_interactively (function=24380921,
      record_flag=23861249, keys=23920644) at callint.c:884
  #118 0x0104ca4e in Fcommand_execute (cmd=24380921, record_flag=23861249,
      keys=23861249, special=23861249) at keyboard.c:9751
  #119 0x01053289 in command_loop_1 () at keyboard.c:1780
  #120 0x0100a81b in internal_condition_case (bfun=0x1052f49 <command_loop_1>,
      handlers=23925361, hfun=0x104d3a7 <cmd_error>) at eval.c:1465
  #121 0x010479c7 in command_loop_2 () at keyboard.c:1318
  #122 0x0100a750 in internal_catch (tag=23919641,
      func=0x10479a4 <command_loop_2>, arg=23861249) at eval.c:1211
  #123 0x010477e3 in command_loop () at keyboard.c:1297
  #124 0x01047877 in recursive_edit_1 () at keyboard.c:990
  #125 0x0104798d in Frecursive_edit () at keyboard.c:1051
  #126 0x010029dd in main (argc=2, argv=0xa23fa8) at emacs.c:1786

  Lisp Backtrace:
  "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"
  0x1993b04 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"

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

[Eli Zaretskii]

FWIW, I found that I can prevent this crash with the simple change
below.  It registers the frame in Vframe_alist before the menu bar is
constructed, so if the latter signals an error, the frame whose menu
could not be built is nonetheless recorded in Vframe_alist, and thus
check_glyph_memory will free its glyph matrices.

The question is: is the crash an artifact of how check_glyph_memory
checks for glyph memory leaks, or does the crash indicate some deeper
problem?  In other words, is it kosher for Fx_create_frame to be
entered recursively?

Note that the version of Fx_create_frame in xfns.c creates the menu
_after_ the frame is registered, and not as part of the window
creation in x_window.  Jason, can you tell whether it is okay to move
the code that creates the menu on w32 from w32_window to
Fx_create_frame, and do that after the call to x_icon and x_make_gc?

Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.261
diff -c -r1.261 w32fns.c
*** src/w32fns.c	14 Dec 2005 20:58:33 -0000	1.261
--- src/w32fns.c	16 Dec 2005 20:03:49 -0000
***************
*** 4299,4312 ****
    tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
    f->no_split = minibuffer_only || EQ (tem, Qt);
  
    w32_window (f, window_prompting, minibuffer_only);
    x_icon (f, parameters);
- 
    x_make_gc (f);
  
    /* Now consider the frame official.  */
    FRAME_W32_DISPLAY_INFO (f)->reference_count++;
-   Vframe_list = Fcons (frame, Vframe_list);
  
    /* We need to do this after creating the window, so that the
       icon-creation functions can say whose icon they're describing.  */
--- 4299,4315 ----
    tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
    f->no_split = minibuffer_only || EQ (tem, Qt);
  
+   /* Do this before the call to w32_window, since that can call Feval
+      (e.g., to compute the frame's menu bar) and throw an error, which
+      will leave this frame unregistered.  */
+   Vframe_list = Fcons (frame, Vframe_list);
+ 
    w32_window (f, window_prompting, minibuffer_only);
    x_icon (f, parameters);
    x_make_gc (f);
  
    /* Now consider the frame official.  */
    FRAME_W32_DISPLAY_INFO (f)->reference_count++;
  
    /* We need to do this after creating the window, so that the
       icon-creation functions can say whose icon they're describing.  */

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

[Richard M. Stallman]

    +   /* Do this before the call to w32_window, since that can call Feval
    +      (e.g., to compute the frame's menu bar) and throw an error, which
    +      will leave this frame unregistered.  */
    +   Vframe_list = Fcons (frame, Vframe_list);
    + 
	w32_window (f, window_prompting, minibuffer_only);
	x_icon (f, parameters);
	x_make_gc (f);


Changing Vframe_list so early, before calling w32_window, could be
dangerous.  What if some part of window creation fails, or x_icon, or
x_make_gc?  While I am not sure of how things worn on Windows, if
those fail I suspect it will leave a bad situation.  You would not want
such a frame to be considered live.

I think the right fix is keep the setting of Vframe_list where it was,
and instead move the creation of the menu bar out of w32_window and
put it at a later place in Fx_create_frame.  That would make the code
more like what it is in xfns.c, where the menu bar creation step
is done later, after the frame is already safely in existence.

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

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org, jasonr@gnu.org
> Date: Fri, 16 Dec 2005 20:05:24 -0500
> 
>     +   /* Do this before the call to w32_window, since that can call Feval
>     +      (e.g., to compute the frame's menu bar) and throw an error, which
>     +      will leave this frame unregistered.  */
>     +   Vframe_list = Fcons (frame, Vframe_list);
>     + 
> 	w32_window (f, window_prompting, minibuffer_only);
> 	x_icon (f, parameters);
> 	x_make_gc (f);
> 
> 
> Changing Vframe_list so early, before calling w32_window, could be
> dangerous.  What if some part of window creation fails, or x_icon, or
> x_make_gc?  While I am not sure of how things worn on Windows, if
> those fail I suspect it will leave a bad situation.  You would not want
> such a frame to be considered live.

AFAICS, only x_icon can throw an error.  We could arrange for removing
the failed frame from the list (and free its glyph matrices while at
that) if an error is thrown.

> I think the right fix is keep the setting of Vframe_list where it was,
> and instead move the creation of the menu bar out of w32_window and
> put it at a later place in Fx_create_frame.

I agree.  I asked Jason whether such a change could do any harm on
Windows.

So I understand from your response that it is okay for Fx_create_frame
to be entered recursively, yes?

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

[Richard M. Stallman]

    So I understand from your response that it is okay for Fx_create_frame
    to be entered recursively, yes?

There is a part of it which should not be entered recursively, while
the frame is partially set up.  Before or after that part is ok.