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: Sun, 11 Dec 2005 22:21:29 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1134332635 16892 80.91.229.2 (11 Dec 2005 20:23:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2005 20:23:55 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 21:23:44 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ElXhf-0005sr-Q8 for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2005 21:21:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElXi7-0006Mj-PZ for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2005 15:22:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ElXhq-0006M2-DV for emacs-devel@gnu.org; Sun, 11 Dec 2005 15:22:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ElXho-0006KK-DF for emacs-devel@gnu.org; Sun, 11 Dec 2005 15:22:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElXho-0006K8-7I for emacs-devel@gnu.org; Sun, 11 Dec 2005 15:22:00 -0500 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ElXjP-00006p-Al for emacs-devel@gnu.org; Sun, 11 Dec 2005 15:23:39 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-241-8.inter.net.il [83.130.241.8]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DDQ84636 (AUTH halo1); Sun, 11 Dec 2005 22:21:24 +0200 (IST) Original-To: drew.adams@oracle.com, cyd@stupidchicken.com In-reply-to: (message from Eli Zaretskii on Fri, 09 Dec 2005 15:17:06 +0200) 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:47477 Archived-At: > Date: Fri, 09 Dec 2005 15:17:06 +0200 > From: Eli Zaretskii > Cc: Chong Yidong , 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(#) 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) 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?