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

[Eli Zaretskii <eliz@gnu.org>]

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