From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [drew.adams@oracle.com: RE: weird defadvice bug withbyte-compilation] Date: Fri, 9 Dec 2005 10:37:16 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134159559 30862 80.91.229.2 (9 Dec 2005 20:19:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2005 20:19:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 09 21:19:16 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ekoft-000512-R4 for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2005 21:17:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkogF-0003Ie-EA for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2005 15:17:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ekn81-0007wI-GZ for emacs-devel@gnu.org; Fri, 09 Dec 2005 13:37:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ekn7y-0007vg-Jj for emacs-devel@gnu.org; Fri, 09 Dec 2005 13:37:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ekn7u-0007um-G8 for emacs-devel@gnu.org; Fri, 09 Dec 2005 13:37:51 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Ekn98-0001Er-W9 for emacs-devel@gnu.org; Fri, 09 Dec 2005 13:39:07 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jB9IbO2l004147 for ; Fri, 9 Dec 2005 11:37:24 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB9IbOm3029574 for ; Fri, 9 Dec 2005 11:37:24 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-105-225.vpn.oracle.com [141.144.105.225]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jB9IbMf9029563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 9 Dec 2005 11:37:23 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:47337 Archived-At: 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)... . Typing "C-x C-c" at this point, i.e., after the above traceback was shown, does pop up the Emacs Abort Dialog. Thanks fo looking into this problem on Windows. What Eli reports is exactly what I saw and see. The Lisp error is thrown for a good reason, AFAICT: `my-mode' was never defined. Drew, should it be? Yes and no. Yes, for my program to work; no, to reproduce the bug. If it is defined explicitly, then the error does not occur. (The error to be concerned about here is obviously the fatal error that results, not the error of the variable not being bound.) Here is some background on the variable binding, however - the real context: 1. In file foo.el, I do the defadvice before I do a define-minor-mode that defines (and binds) the variable my-mode. If I move the defadvice in foo.el after the define-minor-mode, there is no problem. ("So", the doctor said, "if it hurts, just don't do that".) However, I'm not clear on why I should need to do that. Does the defadvice really need my-mode to be bound? I thought that defadvice's last arg (BODY), in this case just my-mode, was treated by defadvice as unevaluated code, to be evaluated only when the advised function is called. In the case in question, the function next-history-element is never called, so I don't understand why my-mode is evaluated. It is apparently evaluated by x-create-frame, but I don't see why. Looking further up the debug stack, there is an automatic byte-compilation of the advised next-history-element. It's not clear to me if the variable is evaluated at that point or just by x-create-frame. I don't see why x-create-frame would evaluate the variable, and I don't see why the variable would be evaluated during byte-compilation. 2. Secondly, I'm not real clear on the use of define-minor-mode, I guess. This library works with both Emacs 20 and 22. For Emacs 20, I do an explicit defcustom to define my-mode, and I do that before defining the minor-mode function my-mode - no problem. For Emacs 22, I do the define-minor-mode at the same place I do the Emacs 20 defun my-mode. I was expecting that define-minor-mode would DTRT: it would somehow define the variable early enough - but I guess that's not possible. I will move the define-minor-mode forward, but it makes the library a bit less readable. I like to put all defcustoms and defvars at the beginning (after macro definitions), before any function definitions. I think of define-minor-mode as essentially a function definition, but it is in fact also a variable definition, so I guess I need to move it forward. You'll say that defadvice also (re)defines a function, and the only need here is to move the define-minor-mode before the defadvice. That's true. There was a certain logic to the order of the function definitions, but that's less important now than making things work! I'll move the define-minor-mode forward, and say no more. That changes nothing about the bug, of course - Emacs should not end in a fatal error just because a variable is not bound. And I still have the question about why the unbound variable was evaluated (during advice compilation? during frame creation?). -- Oops - last minute addition. It just occurred to me that the unbound variable is being evaluated by x-create-frame in order to set the minor-mode mode-line indication. (Should users need to be concerned about binding that variable, even though they have used define-minor-mode?) I think, then, that there may be a second bug here, besides ungracefully treating an unbound variable. Again, however, there seem to be several things interacting here, because I found that if I remove any part of the code I submitted with the bug, the bug goes away. This suggests that it involves: 1) the mode-line indication (minor-mode-map-alist), 2) the menu-enable condition (that's the code that provokes the error message by evaluating the unbound variable), 3) the keymap, 4) the defadvice in foo.el, and 5) the defadvice in bar.el. Clarification welcome. Thanks, Drew 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?