From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Date: Fri, 09 Dec 2005 15:17:06 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1134143556 7366 80.91.229.2 (9 Dec 2005 15:52:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2005 15:52:36 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 09 16:52:27 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EkkTk-0001HT-Al for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2005 16:48:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkkU4-0003Wb-FQ for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2005 10:48:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eki8A-0005FF-DP for emacs-devel@gnu.org; Fri, 09 Dec 2005 08:17:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eki88-0005D6-IY for emacs-devel@gnu.org; Fri, 09 Dec 2005 08:17:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eki87-0005CT-6h for emacs-devel@gnu.org; Fri, 09 Dec 2005 08:17:43 -0500 Original-Received: from [192.114.186.17] (helo=gandalf.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Eki9I-0007Ea-Vb for emacs-devel@gnu.org; Fri, 09 Dec 2005 08:18:57 -0500 Original-Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HFG01485; Fri, 9 Dec 2005 15:17:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-245-91.inter.net.il [84.228.245.91]) by nitzan.inter.net.il (MOS 3.7.2-GA) with ESMTP id CEL15040 (AUTH halo1); Fri, 9 Dec 2005 15:17:05 +0200 (IST) Original-To: "Drew Adams" In-reply-to: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:47305 Archived-At: > From: "Drew Adams" > 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(#) display-buffer(#) 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 , handlers=23925361, hfun=0x104d397 ) at eval.c:1465 #13 0x010479b7 in command_loop_2 () at keyboard.c:1315 #14 0x0100a750 in internal_catch (tag=23949793, func=0x1047994 , 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?