* [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] @ 2005-11-28 4:46 Richard M. Stallman 0 siblings, 0 replies; 23+ messages in thread From: Richard M. Stallman @ 2005-11-28 4:46 UTC (permalink / raw) Would someone please investigate this bug, and ack? ------- Start of forwarded message ------- From: "Drew Adams" <drew.adams@oracle.com> To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org> Date: Tue, 22 Nov 2005 09:32:25 -0800 In-Reply-To: <MEEKKIABFKKDFJMPIOEBKEHKCNAA.drew.adams@oracle.com> X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Subject: RE: weird defadvice bug with byte-compilation Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Not sure if anyone is looking into this bug. I know it sounds as if it's quite particular (corner case), but I suspect that this may point to something improper in the byte-compiler code. And it does systematically produce a fatal error. - Drew - ---------- This is a weird one. I've pared it down to the bare bones, I think - if I comment out any part of this, the bug doesn't occur. This obviously comes from a larger context - when it is pared down, the code doesn't make much sense, of course. If the stuff is in the same file, or the order is different, no bug (error). It must be like this: two files, one of which is compiled and required by the other. And the requiring file must have "compile" in its defadvice. Two files: File 1: foo.el -------------- (defvar mymap nil "") (let ((map (make-sparse-keymap "II"))) (setq mymap (make-sparse-keymap)) (define-key menu-bar-search-menu [ise] '("" . ise)) (put 'ise 'menu-enable '(and my-mode)) (push (cons 'my-mode mymap) minor-mode-map-alist)) (defadvice next-history-element (after ffff activate) "" my-mode) (provide 'foo) File 2: bar.el -------------- (defconst special-display-regexps '("[ ]?[*][^*]+[*]")) (defvar drews-lisp-dir "C:\\drews-lisp-20" "") (setq load-path (append (list drews-lisp-dir) load-path)) (defadvice occur-mode-goto-occurrence (around jjjjjj activate compile) "" ad-do-it) (require 'foo) Instructions: ------------- 1. emacs -q 2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20 or 22). `C-x C-c'. 3. emacs -q (Emacs 22) 4. Visit bar.el - don't load it. 5. Select everything in bar.el except the (require 'foo), and do `eval-region'. 6. Put the cursor just after the (require 'foo) and do `C-x C-e'. (Don't select it and do eval-region - that doesn't produce the bug!) You will get this error 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) 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 "??? \n \f \x0e\x0e?? 7. `C-x C-c' You will get a pop-up message with Yes/No buttons that says this: Emacs Abort Dialog "A fatal error has occurred! Would you like to attach a debugger? Select YES to debu, NO to abort Emacs" If you select Yes, you get a Window program exception and an invitation to send the details to Microsoft. The error report contents are these: Exception Information Code 0x80000003 Flags: 0x00000000 Record: 0x0000000000000000 (didn't count 'em) Address: 0x0000000077f75a58 System Information Windows NT 5.1 Build: 2600 CPU Vendor Code etc. blah blah blah Module 1 emacs.exe blah blah Module 2 ntdll.dll blah blah Module 3 kernel32.dll blah blah Module 4 msvcrt.dll blah blah etc. etc. ------------------------------------ In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ------- End of forwarded message ------- ^ permalink raw reply [flat|nested] 23+ messages in thread
* [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] @ 2005-12-05 2:36 Richard Stallman 2005-12-07 18:55 ` Chong Yidong 0 siblings, 1 reply; 23+ messages in thread From: Richard Stallman @ 2005-12-05 2:36 UTC (permalink / raw) Would someone please investigate this bug, and ack? It needs to be debugged for the release. ------- Start of forwarded message ------- From: "Drew Adams" <drew.adams@oracle.com> To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org> Date: Tue, 22 Nov 2005 09:32:25 -0800 In-Reply-To: <MEEKKIABFKKDFJMPIOEBKEHKCNAA.drew.adams@oracle.com> X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Subject: RE: weird defadvice bug with byte-compilation Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Not sure if anyone is looking into this bug. I know it sounds as if it's quite particular (corner case), but I suspect that this may point to something improper in the byte-compiler code. And it does systematically produce a fatal error. - Drew - ---------- This is a weird one. I've pared it down to the bare bones, I think - if I comment out any part of this, the bug doesn't occur. This obviously comes from a larger context - when it is pared down, the code doesn't make much sense, of course. If the stuff is in the same file, or the order is different, no bug (error). It must be like this: two files, one of which is compiled and required by the other. And the requiring file must have "compile" in its defadvice. Two files: File 1: foo.el -------------- (defvar mymap nil "") (let ((map (make-sparse-keymap "II"))) (setq mymap (make-sparse-keymap)) (define-key menu-bar-search-menu [ise] '("" . ise)) (put 'ise 'menu-enable '(and my-mode)) (push (cons 'my-mode mymap) minor-mode-map-alist)) (defadvice next-history-element (after ffff activate) "" my-mode) (provide 'foo) File 2: bar.el -------------- (defconst special-display-regexps '("[ ]?[*][^*]+[*]")) (defvar drews-lisp-dir "C:\\drews-lisp-20" "") (setq load-path (append (list drews-lisp-dir) load-path)) (defadvice occur-mode-goto-occurrence (around jjjjjj activate compile) "" ad-do-it) (require 'foo) Instructions: ------------- 1. emacs -q 2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20 or 22). `C-x C-c'. 3. emacs -q (Emacs 22) 4. Visit bar.el - don't load it. 5. Select everything in bar.el except the (require 'foo), and do `eval-region'. 6. Put the cursor just after the (require 'foo) and do `C-x C-e'. (Don't select it and do eval-region - that doesn't produce the bug!) You will get this error 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) 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 "??? \n \f \x0e\x0e?? 7. `C-x C-c' You will get a pop-up message with Yes/No buttons that says this: Emacs Abort Dialog "A fatal error has occurred! Would you like to attach a debugger? Select YES to debu, NO to abort Emacs" If you select Yes, you get a Window program exception and an invitation to send the details to Microsoft. The error report contents are these: Exception Information Code 0x80000003 Flags: 0x00000000 Record: 0x0000000000000000 (didn't count 'em) Address: 0x0000000077f75a58 System Information Windows NT 5.1 Build: 2600 CPU Vendor Code etc. blah blah blah Module 1 emacs.exe blah blah Module 2 ntdll.dll blah blah Module 3 kernel32.dll blah blah Module 4 msvcrt.dll blah blah etc. etc. ------------------------------------ In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ------- End of forwarded message ------- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-05 2:36 Richard Stallman @ 2005-12-07 18:55 ` Chong Yidong 2005-12-08 4:53 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Chong Yidong @ 2005-12-07 18:55 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > 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). > From: "Drew Adams" <drew.adams@oracle.com> > > File 1: foo.el > -------------- > > (defvar mymap nil "") > > (let ((map (make-sparse-keymap "II"))) > (setq mymap (make-sparse-keymap)) > (define-key menu-bar-search-menu [ise] '("" . ise)) > (put 'ise 'menu-enable '(and my-mode)) > (push (cons 'my-mode mymap) minor-mode-map-alist)) > > (defadvice next-history-element (after ffff activate) "" my-mode) > > (provide 'foo) > > File 2: bar.el > -------------- > > (defconst special-display-regexps '("[ ]?[*][^*]+[*]")) > > (defvar drews-lisp-dir "C:\\drews-lisp-20" "") > (setq load-path (append (list drews-lisp-dir) load-path)) > > > (defadvice occur-mode-goto-occurrence > (around jjjjjj activate compile) > "" > ad-do-it) > > (require 'foo) > > Instructions: > ------------- > > 1. emacs -q > > 2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20 > or 22). `C-x C-c'. > > 3. emacs -q (Emacs 22) > > 4. Visit bar.el - don't load it. > > 5. Select everything in bar.el except the (require 'foo), and > do `eval-region'. > > 6. Put the cursor just after the (require 'foo) and do `C-x > C-e'. (Don't select it and do eval-region - that doesn't > produce the bug!) > > 7. `C-x C-c' > > You will get a pop-up message with Yes/No buttons that says this: > > Emacs Abort Dialog > > "A fatal error has occurred! Would you like to attach a > debugger? Select YES to debu, NO to abort Emacs" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-07 18:55 ` Chong Yidong @ 2005-12-08 4:53 ` Richard M. Stallman 2005-12-08 16:14 ` Drew Adams 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-08 4:53 UTC (permalink / raw) Cc: drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-08 4:53 ` Richard M. Stallman @ 2005-12-08 16:14 ` Drew Adams 2005-12-09 13:17 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Drew Adams @ 2005-12-08 16:14 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-08 16:14 ` Drew Adams @ 2005-12-09 13:17 ` Eli Zaretskii 2005-12-09 14:07 ` Chong Yidong ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Eli Zaretskii @ 2005-12-09 13:17 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel > 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-09 13:17 ` Eli Zaretskii @ 2005-12-09 14:07 ` Chong Yidong 2005-12-10 4:14 ` Richard M. Stallman 2005-12-11 20:21 ` Eli Zaretskii 2 siblings, 0 replies; 23+ messages in thread From: Chong Yidong @ 2005-12-09 14:07 UTC (permalink / raw) Cc: Drew Adams, emacs-devel > 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-c" at this point, i.e., after the above traceback > was shown, does pop up the Emacs Abort Dialog. On GNU/Linux, `C-x C-c' at this point just exits Emacs. I didn't see any abort dialog. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-09 13:17 ` Eli Zaretskii 2005-12-09 14:07 ` Chong Yidong @ 2005-12-10 4:14 ` Richard M. Stallman 2005-12-11 20:21 ` Eli Zaretskii 2 siblings, 0 replies; 23+ messages in thread From: Richard M. Stallman @ 2005-12-10 4:14 UTC (permalink / raw) Cc: cyd, drew.adams, emacs-devel 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))) I think I see the reason for this error: (let ((map (make-sparse-keymap "II"))) (setq mymap (make-sparse-keymap)) (define-key menu-bar-search-menu [ise] '("" . ise)) (put 'ise 'menu-enable '(and my-mode)) The menu command's enable condition tests a void variable. So this error seems to be correct. It sounds like some frame's glyph matrices were not freed for some reason? Or maybe they were originally used, and counted, more times than they should have been. So I think the first question is, was glyph_matrix_count correct before check_glyph_memory was called? If so, there must be a bug in free_glyphs. If it was not correct, then how did it get to be wrong? I suspect that it has to do with getting an error while part way through creating a frame. Maybe that left an inconsistent value for glyph_matrix_count. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-09 13:17 ` Eli Zaretskii 2005-12-09 14:07 ` Chong Yidong 2005-12-10 4:14 ` Richard M. Stallman @ 2005-12-11 20:21 ` Eli Zaretskii 2005-12-12 5:23 ` Richard M. Stallman 2 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-11 20:21 UTC (permalink / raw) Cc: emacs-devel > Date: Fri, 09 Dec 2005 15:17:06 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: Chong Yidong <cyd@stupidchicken.com>, 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(#<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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-11 20:21 ` Eli Zaretskii @ 2005-12-12 5:23 ` Richard M. Stallman 2005-12-12 6:11 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-12 5:23 UTC (permalink / raw) Cc: cyd, drew.adams, emacs-devel Second, the crash is somehow related to the fact that x-create-frame is called from within itself, or something like that: Very interesting. Can you send me the C backtrace? That's what matters here. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-12 5:23 ` Richard M. Stallman @ 2005-12-12 6:11 ` Eli Zaretskii 2005-12-13 3:14 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-12 6:11 UTC (permalink / raw) Cc: cyd, drew.adams, emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Mon, 12 Dec 2005 00:23:33 -0500 > > Second, the crash is somehow related to the fact that x-create-frame > is called from within itself, or something like that: > > Very interesting. Can you send me the C backtrace? That's what > matters here. I posted the C backtrace in this thread. Here is a more full version: Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to thread 2924.0x948] 0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll (gdb) bt 40 #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll #1 0x011319c7 in w32_abort () at w32fns.c:8953 #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:2170 #4 0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2075 #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:9751 #11 0x01053279 in command_loop_1 () at keyboard.c:1780 #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:1318 #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:1285 #16 0x01047867 in recursive_edit_1 () at keyboard.c:990 #17 0x0104797d in Frecursive_edit () at keyboard.c:1051 #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876 #19 0x011094f9 in Fbyte_code (bytestr=26968867, vector=27021828, maxdepth=32) at bytecode.c:694 #20 0x0100baf6 in Feval (form=26208213) at eval.c:2225 #21 0x0100bdc3 in Fprogn (args=26207965) at eval.c:432 #22 0x0109cbaa in Fsave_window_excursion (args=26207965) at window.c:6368 #23 0x01109ef2 in Fbyte_code (bytestr=26969027, vector=29856260, maxdepth=224) at bytecode.c:855 #24 0x0100bfae in funcall_lambda (fun=29723972, nargs=2, arg_vector=0x82cbd4) at eval.c:3066 #25 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934 #26 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371 #27 0x0100d9c1 in apply1 (fn=24109177, arg=26176261) at eval.c:2632 #28 0x0100b270 in call_debugger (arg=26176261) at eval.c:289 #29 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045, sig=23925529, data=26176285, debugger_value_ptr=0x82cce8) at eval.c:1815 #30 0x0100c93a in Fsignal (error_symbol=23925529, data=26176285) at eval.c:1642 #31 0x01005ad2 in Fsymbol_value (symbol=29457225) at data.c:1143 #32 0x0100b84c in Feval (form=29457225) at eval.c:2105 #33 0x0100e1d4 in Fand (args=25815637) at eval.c:353 #34 0x0100bbdb in Feval (form=25815653) at eval.c:2166 #35 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>, arg=25815653, handlers=23925361, hfun=0x104b17c <menu_item_eval_property_1>) at eval.c:1506 #36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193 #37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0) at keyboard.c:7380 #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 (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" "byte-compile-variable-ref" "byte-compile-form" "byte-compile-body" "byte-compile-let" "byte-compile-form" "byte-compile-top-level" "byte-compile-lambda" 0x1d22e84 PVEC_COMPILED "funcall" "byte-compile" "ad-compile-function" "ad-activate-advised-definition" "ad-activate" "byte-code" "require" "eval" "eval-last-sexp-1" "eval-last-sexp" "call-interactively" (gdb) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-12 6:11 ` Eli Zaretskii @ 2005-12-13 3:14 ` Richard M. Stallman 2005-12-13 4:39 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-13 3:14 UTC (permalink / raw) Cc: cyd, drew.adams, emacs-devel #36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193 #37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0) at keyboard.c:7380 #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 (More stack frames follow...) You cut it off just as it's starting to get interesting! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-13 3:14 ` Richard M. Stallman @ 2005-12-13 4:39 ` Eli Zaretskii 2005-12-13 23:33 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-13 4:39 UTC (permalink / raw) Cc: emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Mon, 12 Dec 2005 22:14:53 -0500 > > #36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193 > #37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0) > at keyboard.c:7380 > #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, > pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 > #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, > prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 > (More stack frames follow...) > > You cut it off just as it's starting to get interesting! Tell me what you want to know or see, and I will make sure it's not cut off. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-13 4:39 ` Eli Zaretskii @ 2005-12-13 23:33 ` Richard M. Stallman 2005-12-14 19:38 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-13 23:33 UTC (permalink / raw) Cc: emacs-devel > #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, > pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 > #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, > prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 > (More stack frames follow...) > > You cut it off just as it's starting to get interesting! Tell me what you want to know or see, and I will make sure it's not cut off. Where does it come from in Fx_create_frame? If there are two frames that call Fx_create_frame, I need to see both. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-13 23:33 ` Richard M. Stallman @ 2005-12-14 19:38 ` Eli Zaretskii 2005-12-15 2:09 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-14 19:38 UTC (permalink / raw) Cc: emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: emacs-devel@gnu.org > Date: Tue, 13 Dec 2005 18:33:42 -0500 > > > #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504, > > pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 > > #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893, > > prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468 > > (More stack frames follow...) > > > > You cut it off just as it's starting to get interesting! > > Tell me what you want to know or see, and I will make sure it's not > cut off. > > Where does it come from in Fx_create_frame? > > If there are two frames that call Fx_create_frame, I need > to see both. Unfortunately, I cannot show this in the C traceback, because GDB chokes on the next stack frame: #39 0x0112ae03 in single_menu_item (key=28443961, item=0, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9, notreal=17085537, maxdepth=24660221) at w32menu.c:468 #41 0x00000000 in ?? () from #42 0x00000009 in ?? () #43 0x0104b461 in parse_menu_item (item=480, notreal=8573128, inmenubar=18001130) at keyboard.c:7376 #44 0x01c76008 in ?? () #45 0x000001e0 in ?? () #46 0x0082d0c8 in ?? () #47 0x0112acea in grow_menu_items () at w32menu.c:329 #48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005 Cannot access memory at address 0x1b016c14 But the Lisp traceback clearly shows the recursive call: "x-create-frame" "x-create-frame-with-faces" "make-frame" "special-display-popup-frame" "pop-to-buffer" "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" "byte-compile-variable-ref" "byte-compile-form" "byte-compile-body" "byte-compile-let" "byte-compile-form" "byte-compile-top-level" "byte-compile-lambda" 0x1c2cf24 PVEC_COMPILED "funcall" "byte-compile" "ad-compile-function" "ad-activate-advised-definition" "ad-activate" "byte-code" "require" "eval" "eval-last-sexp-1" "eval-last-sexp" "call-interactively" I think the recursion happens when Emacs builds the menu bar for the new frame. The C functions that build menu items, which show in the C traceback, are an evidence to that effect. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-14 19:38 ` Eli Zaretskii @ 2005-12-15 2:09 ` Richard M. Stallman 2005-12-15 4:46 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-15 2:09 UTC (permalink / raw) Cc: emacs-devel Unfortunately, I cannot show this in the C traceback, because GDB chokes on the next stack frame: #39 0x0112ae03 in single_menu_item (key=28443961, item=0, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9, notreal=17085537, maxdepth=24660221) at w32menu.c:468 #41 0x00000000 in ?? () from #42 0x00000009 in ?? () #43 0x0104b461 in parse_menu_item (item=480, notreal=8573128, inmenubar=18001130) at keyboard.c:7376 #44 0x01c76008 in ?? () #45 0x000001e0 in ?? () #46 0x0082d0c8 in ?? () #47 0x0112acea in grow_menu_items () at w32menu.c:329 #48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005 Cannot access memory at address 0x1b016c14 This means the stack is corrupted. We need to find out why and how, because that could be the most important bug. This is probably straightforward and not too hard. It has to happen inside that call to x_y_to_hpos_vpos. By inserting some breakpoints at places where control passes within that frame, and at each one examining the backtrace, you can see it gets clobbered between point X and point Y. Then try again with breakpoints or stepping between X and Y, and localize it more narrowly. Eventually you find exactly where it happens, and the problem is usually obvious when you look at the code in that line. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-15 2:09 ` Richard M. Stallman @ 2005-12-15 4:46 ` Eli Zaretskii 2005-12-16 1:51 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-15 4:46 UTC (permalink / raw) Cc: emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: emacs-devel@gnu.org > Date: Wed, 14 Dec 2005 21:09:16 -0500 > > Unfortunately, I cannot show this in the C traceback, because GDB > chokes on the next stack frame: > > #39 0x0112ae03 in single_menu_item (key=28443961, item=0, > pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 > #40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9, > notreal=17085537, maxdepth=24660221) at w32menu.c:468 > #41 0x00000000 in ?? () from > #42 0x00000009 in ?? () > #43 0x0104b461 in parse_menu_item (item=480, notreal=8573128, > inmenubar=18001130) at keyboard.c:7376 > #44 0x01c76008 in ?? () > #45 0x000001e0 in ?? () > #46 0x0082d0c8 in ?? () > #47 0x0112acea in grow_menu_items () at w32menu.c:329 > #48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005 > Cannot access memory at address 0x1b016c14 > > This means the stack is corrupted. We need to find out why and how, > because that could be the most important bug. No, the stack is not corrupted. The problem is that latest versions of GDB modified their way of analyzing function prologues, and that caused major regressions in stack backtraces on x86, especially with latest versions of GCC. That has been discussed extensively on the GDB mailing list during the last year. GDB 6.4 is supposed to improve on that, but I don't yet have its Windows port. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 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 0 siblings, 2 replies; 23+ messages in thread From: Richard M. Stallman @ 2005-12-16 1:51 UTC (permalink / raw) Cc: emacs-devel > This means the stack is corrupted. We need to find out why and how, > because that could be the most important bug. No, the stack is not corrupted. The problem is that latest versions of GDB modified their way of analyzing function prologues, and that caused major regressions in stack backtraces on x86, especially with latest versions of GCC. That has been discussed extensively on the GDB mailing list during the last year. GDB 6.4 is supposed to improve on that, but I don't yet have its Windows port. In that case, with a breakpoint at x_y_to_hpos_vpos do you see more stack trace info? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-16 1:51 ` Richard M. Stallman @ 2005-12-16 19:48 ` Eli Zaretskii 2005-12-16 20:14 ` Eli Zaretskii 1 sibling, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2005-12-16 19:48 UTC (permalink / raw) Cc: emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: emacs-devel@gnu.org > Date: Thu, 15 Dec 2005 20:51:15 -0500 > > In that case, with a breakpoint at x_y_to_hpos_vpos > do you see more stack trace info? It was not that easy (needed to find the correct sequence of `step', `finish', and `next' commands to get the info), but the results are below. As you see, menu_item_eval_property, which is called as part of building the menu items, causes Feval to be called, which then enters the debugger, which in turn causes another frame to be created in the middle of creating the frame for *Compile-Log*. #0 new_glyph_matrix (pool=0x0) at dispnew.c:523 #1 0x01084400 in allocate_matrices_for_window_redisplay (w=0x1d77e00) at dispnew.c:2052 #2 0x010846b5 in adjust_frame_glyphs (f=0x1d77000) at dispnew.c:2380 #3 0x01084a94 in adjust_glyphs (f=0x1d77000) at dispnew.c:2081 #4 0x010d910b in x_set_frame_parameters (f=0x1d77000, alist=30471261) at frame.c:2780 #5 0x010dab97 in x_default_parameter (f=0x1d77000, alist=30471949, prop=24041361, deflt=8, xprop=0x12b4870 "menuBar", xclass=0x12b4868 "MenuBar", type=RES_TYPE_NUMBER) at frame.c:3635 #6 0x01137e16 in Fx_create_frame (parameters=30471949) at w32fns.c:4275 #7 0x0100c5da in Ffuncall (nargs=2, args=0x82c3b8) at eval.c:2879 #8 0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40) at bytecode.c:694 #9 0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82c504) at eval.c:3066 #10 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c500) at eval.c:2934 #11 0x011095d9 in Fbyte_code (bytestr=18940947, vector=18940988, maxdepth=24) at bytecode.c:694 #12 0x0100bfae in funcall_lambda (fun=18940900, nargs=1, arg_vector=0x82c644) at eval.c:3066 #13 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c640) at eval.c:2934 #14 0x011095d9 in Fbyte_code (bytestr=18935771, vector=18935916, maxdepth=40) at bytecode.c:694 #15 0x0100bfae in funcall_lambda (fun=18935716, nargs=1, arg_vector=0x82c79c) at eval.c:3066 #16 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c798) at eval.c:2934 #17 0x0100d4ef in call1 (fn=26425137, arg1=30856708) at eval.c:2664 #18 0x0106288f in Fpop_to_buffer (buffer=30856708, other_window=23861249, norecord=23861249) at buffer.c:1726 #19 0x0100c5b3 in Ffuncall (nargs=2, args=0x82c880) at eval.c:2885 #20 0x011095d9 in Fbyte_code (bytestr=30877059, vector=26801924, maxdepth=32) at bytecode.c:694 #21 0x0100baf6 in Feval (form=30363701) at eval.c:2225 #22 0x0100bdc3 in Fprogn (args=30363477) at eval.c:432 #23 0x0109cc0a in Fsave_window_excursion (args=30363477) at window.c:6368 #24 0x01109fd2 in Fbyte_code (bytestr=30876899, vector=30855684, maxdepth=224) at bytecode.c:855 #25 0x0100bfae in funcall_lambda (fun=30392004, nargs=2, arg_vector=0x82cbd4) at eval.c:3066 #26 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934 #27 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371 #28 0x0100d9c1 in apply1 (fn=24109177, arg=30366645) at eval.c:2632 #29 0x0100b270 in call_debugger (arg=30366645) at eval.c:289 #30 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045, sig=23925529, data=30366677, debugger_value_ptr=0x82cce8) at eval.c:1815 #31 0x0100c93a in Fsignal (error_symbol=23925529, data=30366677) at eval.c:1642 #32 0x01005ad2 in Fsymbol_value (symbol=29501537) at data.c:1143 #33 0x0100b84c in Feval (form=29501537) at eval.c:2105 #34 0x0100e1d4 in Fand (args=25851101) at eval.c:353 #35 0x0100bbdb in Feval (form=25851109) at eval.c:2166 #36 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>, arg=25851109, handlers=23925361, hfun=0x104b18c <menu_item_eval_property_1>) at eval.c:1506 #37 0x0104b216 in menu_item_eval_property (sexpr=25851109) at keyboard.c:7193 #38 0x0104b6b1 in parse_menu_item (item=25851149, notreal=0, inmenubar=0) at keyboard.c:7380 #39 0x0112ae23 in single_menu_item (key=29501585, item=0, pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522 #40 0x0112b10e in single_keymap_panes (keymap=29501585, pane_name=0, prefix=9, notreal=17085553, maxdepth=24812205) at w32menu.c:468 #41 parse_single_submenu (item_key, item_name, maps) at w32menu.c:1499 #42 set_frame_menubar (f=0x16ca400, first_time=1, deep_p=1) at w32menu.c:1406 #43 0x0112c4f8 in initialize_frame_menubar () at w32menu.c:1666 #44 0x0113863a in Fx_create_frame (parameters=25605765) at w32fns.c:3951 #45 0x0100c5da in Ffuncall (nargs=2, args=0x82d728) at eval.c:2879 #46 0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40) at bytecode.c:694 #47 0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82d874) at eval.c:3066 #48 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d870) at eval.c:2934 #49 0x011095d9 in Fbyte_code (bytestr=18940883, vector=18940924, maxdepth=24) at bytecode.c:694 #50 0x0100bfae in funcall_lambda (fun=18940836, nargs=1, arg_vector=0x82d9b4) at eval.c:3066 #51 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d9b0) at eval.c:2934 #52 0x011095d9 in Fbyte_code (bytestr=18935707, vector=18935852, maxdepth=40) at bytecode.c:694 #53 0x0100bfae in funcall_lambda (fun=18935652, nargs=1, arg_vector=0x82db0c) at eval.c:3066 #54 0x0100c3a1 in Ffuncall (nargs=2, args=0x82db08) at eval.c:2934 #55 0x0100d4ef in call1 (fn=26426113, arg1=23898116) at eval.c:2664 #56 0x0100c5b3 in Ffuncall (nargs=2, args=0x82dbd0) at eval.c:2885 #57 0x011095d9 in Fbyte_code (bytestr=29441059, vector=30482180, maxdepth=48) at bytecode.c:694 #58 0x0100bfae in funcall_lambda (fun=26442500, nargs=4, arg_vector=0x82dd24) at eval.c:3066 #59 0x0100c3a1 in Ffuncall (nargs=5, args=0x82dd20) at eval.c:2934 #60 0x011095d9 in Fbyte_code (bytestr=29697891, vector=30697668, maxdepth=40) at bytecode.c:694 #61 0x0100bfae in funcall_lambda (fun=30763684, nargs=3, arg_vector=0x82de74) at eval.c:3066 #62 0x0100c3a1 in Ffuncall (nargs=4, args=0x82de70) at eval.c:2934 #63 0x011095d9 in Fbyte_code (bytestr=29697715, vector=30697604, maxdepth=32) at bytecode.c:694 #64 0x0100bfae in funcall_lambda (fun=30763524, nargs=2, arg_vector=0x82dfb4) at eval.c:3066 #65 0x0100c3a1 in Ffuncall (nargs=3, args=0x82dfb0) at eval.c:2934 #66 0x011095d9 in Fbyte_code (bytestr=29622083, vector=30771204, maxdepth=64) at bytecode.c:694 #67 0x0100bfae in funcall_lambda (fun=30781956, nargs=2, arg_vector=0x82e104) at eval.c:3066 #68 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e100) at eval.c:2934 #69 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32) at bytecode.c:694 #70 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e244) at eval.c:3066 #71 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e240) at eval.c:2934 #72 0x011095d9 in Fbyte_code (bytestr=30831027, vector=30817284, maxdepth=32) at bytecode.c:694 #73 0x0100bfae in funcall_lambda (fun=30817156, nargs=2, arg_vector=0x82e384) at eval.c:3066 #74 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e380) at eval.c:2934 #75 0x011095d9 in Fbyte_code (bytestr=30867779, vector=30821892, maxdepth=32) at bytecode.c:694 #76 0x0100bfae in funcall_lambda (fun=30826180, nargs=1, arg_vector=0x82e4c4) at eval.c:3066 #77 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e4c0) at eval.c:2934 #78 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32) at bytecode.c:694 #79 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e604) at eval.c:3066 #80 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e600) at eval.c:2934 #81 0x011095d9 in Fbyte_code (bytestr=29621795, vector=30704260, maxdepth=56) at bytecode.c:694 #82 0x0100bfae in funcall_lambda (fun=30782820, nargs=3, arg_vector=0x82e754) at eval.c:3066 #83 0x0100c3a1 in Ffuncall (nargs=4, args=0x82e750) at eval.c:2934 #84 0x011095d9 in Fbyte_code (bytestr=29621651, vector=30771972, maxdepth=64) at bytecode.c:694 #85 0x0100bfae in funcall_lambda (fun=30783140, nargs=1, arg_vector=0x82e8a4) at eval.c:3066 #86 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e8a0) at eval.c:2934 #87 0x011095d9 in Fbyte_code (bytestr=29621395, vector=30705028, maxdepth=112) at bytecode.c:694 #88 0x0100bfae in funcall_lambda (fun=30784260, nargs=0, arg_vector=0x82ea24) at eval.c:3066 #89 0x0100c3a1 in Ffuncall (nargs=1, args=0x82ea20) at eval.c:2934 #90 0x0100bb14 in Feval (form=29790573) at eval.c:2222 #91 0x0100dca3 in internal_lisp_condition_case (var=29436577, bodyform=29790573, handlers=26199045) at eval.c:1412 #92 0x01109f4b in Fbyte_code (bytestr=29621379, vector=30704900, maxdepth=24) at bytecode.c:884 #93 0x0100bfae in funcall_lambda (fun=30784100, nargs=1, arg_vector=0x82ecf4) at eval.c:3066 #94 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ecf0) at eval.c:2934 #95 0x011095d9 in Fbyte_code (bytestr=30868643, vector=28317700, maxdepth=24) at bytecode.c:694 #96 0x0100bfae in funcall_lambda (fun=26665668, nargs=1, arg_vector=0x82ee34) at eval.c:3066 #97 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ee30) at eval.c:2934 #98 0x011095d9 in Fbyte_code (bytestr=29493683, vector=30699204, maxdepth=56) at bytecode.c:694 #99 0x0100bfae in funcall_lambda (fun=30701988, nargs=2, arg_vector=0x82ef84) at eval.c:3066 #100 0x0100c3a1 in Ffuncall (nargs=3, args=0x82ef80) at eval.c:2934 #101 0x011095d9 in Fbyte_code (bytestr=29493507, vector=30707332, maxdepth=32) at bytecode.c:694 #102 0x0100bfae in funcall_lambda (fun=30701668, nargs=2, arg_vector=0x82f0c4) at eval.c:3066 #103 0x0100c3a1 in Ffuncall (nargs=3, args=0x82f0c0) at eval.c:2934 #104 0x011095d9 in Fbyte_code (bytestr=24006403, vector=24559876, maxdepth=40) at bytecode.c:694 #105 0x0100baf6 in Feval (form=25931277) at eval.c:2225 #106 0x0106a837 in readevalloop (readcharfun=23946201, stream=0x77c5fce0, sourcename=24464883, evalfun=0x100b5de <Feval>, printflag=0, unibyte=23861249, readfun=23861249, start=23861249, end=23861249) at lread.c:1406 #107 0x0106b404 in Fload (file=26699395, noerror=23861249, nomessage=23861297, nosuffix=23861249, must_suffix=23861297) at lread.c:920 #108 0x01078293 in Frequire (feature=29485993, filename=23861249, noerror=23861249) at fns.c:3618 #109 0x0100baf6 in Feval (form=25932213) at eval.c:2225 #110 0x0100c5da in Ffuncall (nargs=2, args=0x82f780) at eval.c:2879 #111 0x011095d9 in Fbyte_code (bytestr=19176851, vector=19177028, maxdepth=64) at bytecode.c:694 #112 0x0100bfae in funcall_lambda (fun=19176812, nargs=1, arg_vector=0x82f8d4) at eval.c:3066 #113 0x0100c3a1 in Ffuncall (nargs=2, args=0x82f8d0) at eval.c:2934 #114 0x011095d9 in Fbyte_code (bytestr=19177683, vector=19177740, maxdepth=32) at bytecode.c:694 #115 0x0100bfae in funcall_lambda (fun=19177644, nargs=1, arg_vector=0x82fa84) at eval.c:3066 #116 0x0100c3a1 in Ffuncall (nargs=2, args=0x82fa80) at eval.c:2934 #117 0x01107938 in Fcall_interactively (function=24380921, record_flag=23861249, keys=23920644) at callint.c:884 #118 0x0104ca4e in Fcommand_execute (cmd=24380921, record_flag=23861249, keys=23861249, special=23861249) at keyboard.c:9751 #119 0x01053289 in command_loop_1 () at keyboard.c:1780 #120 0x0100a81b in internal_condition_case (bfun=0x1052f49 <command_loop_1>, handlers=23925361, hfun=0x104d3a7 <cmd_error>) at eval.c:1465 #121 0x010479c7 in command_loop_2 () at keyboard.c:1318 #122 0x0100a750 in internal_catch (tag=23919641, func=0x10479a4 <command_loop_2>, arg=23861249) at eval.c:1211 #123 0x010477e3 in command_loop () at keyboard.c:1297 #124 0x01047877 in recursive_edit_1 () at keyboard.c:990 #125 0x0104798d in Frecursive_edit () at keyboard.c:1051 #126 0x010029dd in main (argc=2, argv=0xa23fa8) at emacs.c:1786 Lisp Backtrace: "x-create-frame" "x-create-frame-with-faces" "make-frame" "special-display-popup-frame" "pop-to-buffer" "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" "byte-compile-variable-ref" "byte-compile-form" "byte-compile-body" "byte-compile-let" "byte-compile-form" "byte-compile-top-level" "byte-compile-lambda" 0x1993b04 PVEC_COMPILED "funcall" "byte-compile" "ad-compile-function" "ad-activate-advised-definition" "ad-activate" "byte-code" "require" "eval" "eval-last-sexp-1" "eval-last-sexp" "call-interactively" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 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 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-16 20:14 UTC (permalink / raw) Cc: jasonr, emacs-devel FWIW, I found that I can prevent this crash with the simple change below. It registers the frame in Vframe_alist before the menu bar is constructed, so if the latter signals an error, the frame whose menu could not be built is nonetheless recorded in Vframe_alist, and thus check_glyph_memory will free its glyph matrices. The question is: is the crash an artifact of how check_glyph_memory checks for glyph memory leaks, or does the crash indicate some deeper problem? In other words, is it kosher for Fx_create_frame to be entered recursively? Note that the version of Fx_create_frame in xfns.c creates the menu _after_ the frame is registered, and not as part of the window creation in x_window. Jason, can you tell whether it is okay to move the code that creates the menu on w32 from w32_window to Fx_create_frame, and do that after the call to x_icon and x_make_gc? Index: src/w32fns.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v retrieving revision 1.261 diff -c -r1.261 w32fns.c *** src/w32fns.c 14 Dec 2005 20:58:33 -0000 1.261 --- src/w32fns.c 16 Dec 2005 20:03:49 -0000 *************** *** 4299,4312 **** tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN); f->no_split = minibuffer_only || EQ (tem, Qt); w32_window (f, window_prompting, minibuffer_only); x_icon (f, parameters); - x_make_gc (f); /* Now consider the frame official. */ FRAME_W32_DISPLAY_INFO (f)->reference_count++; - Vframe_list = Fcons (frame, Vframe_list); /* We need to do this after creating the window, so that the icon-creation functions can say whose icon they're describing. */ --- 4299,4315 ---- tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN); f->no_split = minibuffer_only || EQ (tem, Qt); + /* Do this before the call to w32_window, since that can call Feval + (e.g., to compute the frame's menu bar) and throw an error, which + will leave this frame unregistered. */ + Vframe_list = Fcons (frame, Vframe_list); + w32_window (f, window_prompting, minibuffer_only); x_icon (f, parameters); x_make_gc (f); /* Now consider the frame official. */ FRAME_W32_DISPLAY_INFO (f)->reference_count++; /* We need to do this after creating the window, so that the icon-creation functions can say whose icon they're describing. */ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-16 20:14 ` Eli Zaretskii @ 2005-12-17 1:05 ` Richard M. Stallman 2005-12-17 8:29 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2005-12-17 1:05 UTC (permalink / raw) Cc: jasonr, emacs-devel + /* Do this before the call to w32_window, since that can call Feval + (e.g., to compute the frame's menu bar) and throw an error, which + will leave this frame unregistered. */ + Vframe_list = Fcons (frame, Vframe_list); + w32_window (f, window_prompting, minibuffer_only); x_icon (f, parameters); x_make_gc (f); Changing Vframe_list so early, before calling w32_window, could be dangerous. What if some part of window creation fails, or x_icon, or x_make_gc? While I am not sure of how things worn on Windows, if those fail I suspect it will leave a bad situation. You would not want such a frame to be considered live. I think the right fix is keep the setting of Vframe_list where it was, and instead move the creation of the menu bar out of w32_window and put it at a later place in Fx_create_frame. That would make the code more like what it is in xfns.c, where the menu bar creation step is done later, after the frame is already safely in existence. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-17 1:05 ` Richard M. Stallman @ 2005-12-17 8:29 ` Eli Zaretskii 2005-12-17 23:59 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2005-12-17 8:29 UTC (permalink / raw) Cc: jasonr, emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: emacs-devel@gnu.org, jasonr@gnu.org > Date: Fri, 16 Dec 2005 20:05:24 -0500 > > + /* Do this before the call to w32_window, since that can call Feval > + (e.g., to compute the frame's menu bar) and throw an error, which > + will leave this frame unregistered. */ > + Vframe_list = Fcons (frame, Vframe_list); > + > w32_window (f, window_prompting, minibuffer_only); > x_icon (f, parameters); > x_make_gc (f); > > > Changing Vframe_list so early, before calling w32_window, could be > dangerous. What if some part of window creation fails, or x_icon, or > x_make_gc? While I am not sure of how things worn on Windows, if > those fail I suspect it will leave a bad situation. You would not want > such a frame to be considered live. AFAICS, only x_icon can throw an error. We could arrange for removing the failed frame from the list (and free its glyph matrices while at that) if an error is thrown. > I think the right fix is keep the setting of Vframe_list where it was, > and instead move the creation of the menu bar out of w32_window and > put it at a later place in Fx_create_frame. I agree. I asked Jason whether such a change could do any harm on Windows. So I understand from your response that it is okay for Fx_create_frame to be entered recursively, yes? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] 2005-12-17 8:29 ` Eli Zaretskii @ 2005-12-17 23:59 ` Richard M. Stallman 0 siblings, 0 replies; 23+ messages in thread From: Richard M. Stallman @ 2005-12-17 23:59 UTC (permalink / raw) Cc: jasonr, emacs-devel So I understand from your response that it is okay for Fx_create_frame to be entered recursively, yes? There is a part of it which should not be entered recursively, while the frame is partially set up. Before or after that part is ok. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2005-12-17 23:59 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-11-28 4:46 [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Richard M. Stallman -- strict thread matches above, loose matches on Subject: below -- 2005-12-05 2:36 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 2005-12-09 14:07 ` Chong Yidong 2005-12-10 4:14 ` Richard M. Stallman 2005-12-11 20:21 ` Eli Zaretskii 2005-12-12 5:23 ` 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
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).