[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: RE: weird defadvice bug with byte-compilation]
From: |
Eli Zaretskii |
Subject: |
Re: address@hidden: RE: weird defadvice bug with byte-compilation] |
Date: |
Sun, 11 Dec 2005 22:21:29 +0200 |
> Date: Fri, 09 Dec 2005 15:17:06 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: Chong Yidong <address@hidden>, address@hidden
>
> 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: address@hidden: RE: weird defadvicebugwithbyte-compilation], (continued)
- RE: address@hidden: RE: weird defadvicebugwithbyte-compilation], Drew Adams, 2005/12/12
- Re: address@hidden: RE: weird defadvicebugwithbyte-compilation], Richard M. Stallman, 2005/12/13
- RE: address@hidden: RE: weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/13
- Re: address@hidden: RE: weirddefadvicebugwithbyte-compilation], Johan Bockgård, 2005/12/13
- RE: address@hidden: RE:weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/13
- RE: address@hidden:RE:weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/13
- Re: address@hidden: RE:weirddefadvicebugwithbyte-compilation], Johan Bockgård, 2005/12/14
- RE: address@hidden:RE:weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/14
- Re: address@hidden:RE:weirddefadvicebugwithbyte-compilation], Johan Bockgård, 2005/12/14
- RE: address@hidden:RE:weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/14
- Re: address@hidden: RE: weird defadvice bug with byte-compilation],
Eli Zaretskii <=
- RE: address@hidden: RE: weird defadvice bug withbyte-compilation], Drew Adams, 2005/12/11
- Re: address@hidden: RE: weird defadvice bug withbyte-compilation], Eli Zaretskii, 2005/12/12
- RE: address@hidden: RE: weird defadvice bugwithbyte-compilation], Drew Adams, 2005/12/12
- RE: address@hidden: RE: weird defadvicebugwithbyte-compilation], Drew Adams, 2005/12/12
- Re: address@hidden: RE: weird defadvicebugwithbyte-compilation], Eli Zaretskii, 2005/12/12
- RE: address@hidden: RE: weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/12
- Re: address@hidden: RE: weirddefadvicebugwithbyte-compilation], Eli Zaretskii, 2005/12/12
- RE: address@hidden: RE:weirddefadvicebugwithbyte-compilation], Drew Adams, 2005/12/13
- Re: address@hidden: RE: weird defadvice bug with byte-compilation], Richard M. Stallman, 2005/12/12
- Re: address@hidden: RE: weird defadvice bug with byte-compilation], Eli Zaretskii, 2005/12/12