From: Eli Zaretskii <eliz@gnu.org>
Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
Subject: Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
Date: Fri, 09 Dec 2005 15:17:06 +0200 [thread overview]
Message-ID: <ur78mjtpp.fsf@gnu.org> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICIEOECPAA.drew.adams@oracle.com>
> 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?
next prev parent reply other threads:[~2005-12-09 13:17 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-05 2:36 [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Richard Stallman
2005-12-07 18:55 ` Chong Yidong
2005-12-08 4:53 ` Richard M. Stallman
2005-12-08 16:14 ` Drew Adams
2005-12-09 13:17 ` Eli Zaretskii [this message]
2005-12-09 14:07 ` Chong Yidong
2005-12-09 18:37 ` [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation] Drew Adams
2005-12-10 4:14 ` [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Richard M. Stallman
2005-12-11 18:17 ` [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation] Drew Adams
2005-12-12 5:23 ` Richard M. Stallman
2005-12-12 5:40 ` [drew.adams@oracle.com: RE: weird defadvice bugwithbyte-compilation] Drew Adams
2005-12-13 3:14 ` Richard M. Stallman
2005-12-13 3:52 ` [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation] Drew Adams
2005-12-13 23:33 ` Richard M. Stallman
2005-12-14 1:05 ` [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation] Drew Adams
2005-12-14 1:24 ` Johan Bockgård
2005-12-14 3:41 ` [drew.adams@oracle.com: Drew Adams
2005-12-14 3:45 ` [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation] Drew Adams
2005-12-14 17:17 ` [drew.adams@oracle.com: Johan Bockgård
2005-12-14 21:29 ` [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation] Drew Adams
2005-12-14 23:43 ` [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation] Johan Bockgård
2005-12-15 1:46 ` [drew.adams@oracle.com:RE:weirddefadvicebugwithbyte-compilation] Drew Adams
2005-12-11 20:21 ` [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Eli Zaretskii
2005-12-11 21:35 ` [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation] Drew Adams
2005-12-12 5:52 ` Eli Zaretskii
2005-12-12 6:11 ` [drew.adams@oracle.com: RE: weird defadvice bugwithbyte-compilation] Drew Adams
2005-12-12 6:44 ` [drew.adams@oracle.com: RE: weird defadvicebugwithbyte-compilation] Drew Adams
2005-12-12 21:22 ` Eli Zaretskii
2005-12-12 21:53 ` [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation] Drew Adams
2005-12-13 4:30 ` Eli Zaretskii
2005-12-13 4:59 ` [drew.adams@oracle.com: Drew Adams
2005-12-12 5:23 ` [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Richard M. Stallman
2005-12-12 6:11 ` Eli Zaretskii
2005-12-13 3:14 ` Richard M. Stallman
2005-12-13 4:39 ` Eli Zaretskii
2005-12-13 23:33 ` Richard M. Stallman
2005-12-14 19:38 ` Eli Zaretskii
2005-12-15 2:09 ` Richard M. Stallman
2005-12-15 4:46 ` Eli Zaretskii
2005-12-16 1:51 ` Richard M. Stallman
2005-12-16 19:48 ` Eli Zaretskii
2005-12-16 20:14 ` Eli Zaretskii
2005-12-17 1:05 ` Richard M. Stallman
2005-12-17 8:29 ` Eli Zaretskii
2005-12-17 23:59 ` Richard M. Stallman
-- strict thread matches above, loose matches on Subject: below --
2005-11-28 4:46 Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ur78mjtpp.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).