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

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> 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?