* bug#15183: 24.3.50; emacs_backtrace.txt @ 2013-08-25 1:01 Drew Adams 2013-08-25 1:51 ` Juanma Barranquero 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2013-08-25 1:01 UTC (permalink / raw) To: 15183 This one was created from an `emacs -Q' session. Dunno how to repro it though. Backtrace: 0x011e6e89 0x011e6efb 0x010d9b0c 0x0114ee2f 0x01145048 0x0107c01a 0x010130c9 0x0101372c 0x0116c449 0x011acacd 0x0116cfc9 0x0116c65f 0x01165ffb 0x0116c478 0x011acacd 0x0116cc05 0x0116c65f 0x0116bfce 0x010e0c44 0x010ec6bc 0x010dd910 0x0116928c 0x010dd24e 0x01168ba6 0x010dd206 0x010dc9bd 0x010dcb79 0x010dae47 0x010010f9 0x767933a6 0x77039f6e 0x77039f41 In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-08-23 on ODIEONE Bzr revision: 113986 rgm@gnu.org-20130823185841-zoy6h1qk433ibrlf Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib CPPFLAGS=-Ic:/Devel/emacs/include' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 1:01 bug#15183: 24.3.50; emacs_backtrace.txt Drew Adams @ 2013-08-25 1:51 ` Juanma Barranquero 2013-08-25 14:36 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Juanma Barranquero @ 2013-08-25 1:51 UTC (permalink / raw) To: Drew Adams; +Cc: 15183 w32_backtrace at w32fns.c:7982 emacs_abort at w32fns.c:8014 terminate_due_to_signal at emacs.c:369 die at alloc.c:6573 XWINDOW at lisp.h:799 set_window_buffer at window.c:3155 delete_frame at frame.c:1251 Fdelete_frame at frame.c:1450 Ffuncall at eval.c:2856 exec_byte_code at bytecode.c:905 funcall_lambda at eval.c:3087 Ffuncall at eval.c:2902 Fcall_interactively at callint.c:836 Ffuncall at eval.c:2860 exec_byte_code at bytecode.c:905 funcall_lambda at eval.c:3021 Ffuncall at eval.c:2902 call4 at eval.c:2701 read_char at keyboard.c:2923 read_key_sequence at keyboard.c:9056 command_loop_1 at keyboard.c:1434 internal_condition_case at eval.c:1339 command_loop_2 at keyboard.c:1161 internal_catch at eval.c:1113 command_loop at keyboard.c:1140 recursive_edit_1 at keyboard.c:779 Frecursive_edit at keyboard.c:843 main at emacs.c:1570 ?? at crt1.c:0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 1:51 ` Juanma Barranquero @ 2013-08-25 14:36 ` martin rudalics 2013-08-25 16:28 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: martin rudalics @ 2013-08-25 14:36 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 15183 > w32_backtrace at w32fns.c:7982 > emacs_abort at w32fns.c:8014 > terminate_due_to_signal at emacs.c:369 > die at alloc.c:6573 > XWINDOW at lisp.h:799 > set_window_buffer at window.c:3155 > delete_frame at frame.c:1251 > Fdelete_frame at frame.c:1450 So IIUC when Drew calls `delete-frame' either (1) the selected frame does not have a minibuffer or (2) the frame to be deleted was selected and the frame selected instead doesn't have a minibuffer. I'm not yet sure what to do but am afraid there's some basic misunderstanding here. Consider choose_minibuf_frame in minibuf.c. It has a comment which says /* I don't think that any frames may validly have a null minibuffer window anymore. */ if (NILP (sf->minibuffer_window)) emacs_abort (); But on my Emacs I can easily do something like (let ((frame (make-frame '((minibuffer . nil))))) (select-frame frame) (minibuffer-window (selected-frame))) which returns nil. So the selected frame's minibuffer window slot may contain nil and unless I'm missing something we have to resolve this issue first. martin ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 14:36 ` martin rudalics @ 2013-08-25 16:28 ` Drew Adams 2013-08-25 17:31 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2013-08-25 16:28 UTC (permalink / raw) To: martin rudalics, Juanma Barranquero; +Cc: 15183 In case it helps, let me repeat what I wrote at the outset for this bug: this crash came from a session started with `emacs -Q', *not* from my setup (so no standalone minibuffer etc.). I do not recall the actions I took after `emacs -Q', but the crash occurred very soon after starting Emacs. It might have been after testing this (for another user), but I don't want to mislead you because I really do not recall: (defadvice ediff-buffers (around pop-up-frames activate) "Use non-nil `pop-up-frames'." (let ((pop-up-frames t)) ad-do-it)) The point is that I did not load *any* of my libraries in the session, IIRC. > So IIUC when Drew calls `delete-frame' either (1) the selected frame > does not have a minibuffer or (2) the frame to be deleted was selected > and the frame selected instead doesn't have a minibuffer. I'm not yet > sure what to do but am afraid there's some basic misunderstanding here. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 16:28 ` Drew Adams @ 2013-08-25 17:31 ` martin rudalics 2013-08-25 17:49 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: martin rudalics @ 2013-08-25 17:31 UTC (permalink / raw) To: Drew Adams; +Cc: Juanma Barranquero, 15183 [-- Attachment #1: Type: text/plain, Size: 384 bytes --] > In case it helps, let me repeat what I wrote at the outset for this bug: > this crash came from a session started with `emacs -Q', *not* from my > setup (so no standalone minibuffer etc.). IIUC at least one frame didn't have a minibuffer since otherwise this error could not have occured. FWIW the attached patch should fix it but I don't have any idea how to test it. martin [-- Attachment #2: frame.c.diff --] [-- Type: text/plain, Size: 3630 bytes --] === modified file 'src/frame.c' --- src/frame.c 2013-08-15 16:28:42 +0000 +++ src/frame.c 2013-08-25 17:22:14 +0000 @@ -1110,6 +1110,44 @@ return 0; } +/* Set minibuf_window preferably to the selected frame's minibuffer + window. If the selected frame doesn't have one, get some other + frame's minibuffer window. not-this is a frame that must be + skipped. select non-zero means select the new window. */ +Lisp_Object +set_minibuf_window (Lisp_Object not_this, int select) +{ + Lisp_Object frames, this, window; + + if (FRAME_HAS_MINIBUF_P (XFRAME (selected_frame))) + window = FRAME_MINIBUF_WINDOW (XFRAME (selected_frame)); + else + FOR_EACH_FRAME (frames, this) + { + if (!EQ (this, not_this) && FRAME_HAS_MINIBUF_P (XFRAME (this))) + { + window = FRAME_MINIBUF_WINDOW (XFRAME (this)); + break; + } + } + + if (!WINDOWP (window)) + emacs_abort (); + else + { + /* Use set_window_buffer instead of Fset_window_buffer (see + discussion of bug#11984, bug#12025, bug#12026). */ + set_window_buffer (window, XWINDOW (minibuf_window)->contents, 0, 0); + minibuf_window = window; + + /* If the previous minibuffer window was selected, select the new + one. */ + if (select) + Fselect_window (minibuf_window, Qnil); + } +} + + /* Delete FRAME. When FORCE equals Qnoelisp, delete FRAME unconditionally. x_connection_closed and delete_terminal use this. Any other value of FORCE implements the semantics @@ -1245,18 +1283,7 @@ /* Don't allow minibuf_window to remain on a deleted frame. */ if (EQ (f->minibuffer_window, minibuf_window)) - { - /* Use set_window_buffer instead of Fset_window_buffer (see - discussion of bug#11984, bug#12025, bug#12026). */ - set_window_buffer (sf->minibuffer_window, - XWINDOW (minibuf_window)->contents, 0, 0); - minibuf_window = sf->minibuffer_window; - - /* If the dying minibuffer window was selected, - select the new one. */ - if (minibuffer_selected) - Fselect_window (minibuf_window, Qnil); - } + set_minibuf_window (frame, minibuffer_selected); /* Don't let echo_area_window to remain on a deleted frame. */ if (EQ (f->minibuffer_window, echo_area_window)) @@ -1683,16 +1710,9 @@ if (NILP (force) && !other_visible_frames (f)) error ("Attempt to make invisible the sole visible or iconified frame"); - /* Don't allow minibuf_window to remain on a deleted frame. */ + /* Don't allow minibuf_window to remain on an invisible frame. */ if (EQ (f->minibuffer_window, minibuf_window)) - { - struct frame *sf = XFRAME (selected_frame); - /* Use set_window_buffer instead of Fset_window_buffer (see - discussion of bug#11984, bug#12025, bug#12026). */ - set_window_buffer (sf->minibuffer_window, - XWINDOW (minibuf_window)->contents, 0, 0); - minibuf_window = sf->minibuffer_window; - } + set_minibuf_window (frame, 0); /* I think this should be done with a hook. */ #ifdef HAVE_WINDOW_SYSTEM @@ -1716,14 +1736,7 @@ /* Don't allow minibuf_window to remain on an iconified frame. */ if (EQ (f->minibuffer_window, minibuf_window)) - { - struct frame *sf = XFRAME (selected_frame); - /* Use set_window_buffer instead of Fset_window_buffer (see - discussion of bug#11984, bug#12025, bug#12026). */ - set_window_buffer (sf->minibuffer_window, - XWINDOW (minibuf_window)->contents, 0, 0); - minibuf_window = sf->minibuffer_window; - } + set_minibuf_window (frame, 0); /* I think this should be done with a hook. */ #ifdef HAVE_WINDOW_SYSTEM ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 17:31 ` martin rudalics @ 2013-08-25 17:49 ` Eli Zaretskii 2013-08-26 13:06 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2013-08-25 17:49 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 15183 > Date: Sun, 25 Aug 2013 19:31:20 +0200 > From: martin rudalics <rudalics@gmx.at> > Cc: Juanma Barranquero <lekktu@gmail.com>, 15183@debbugs.gnu.org > > the attached patch should fix it but I don't have any idea how to > test it. Why, by committing it, of course. Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-25 17:49 ` Eli Zaretskii @ 2013-08-26 13:06 ` martin rudalics 2013-08-26 13:34 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: martin rudalics @ 2013-08-26 13:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 15183 >> the attached patch should fix it but I don't have any idea how to >> test it. > > Why, by committing it, of course. I checked in a slightly different fix. martin ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15183: 24.3.50; emacs_backtrace.txt 2013-08-26 13:06 ` martin rudalics @ 2013-08-26 13:34 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2013-08-26 13:34 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 15183 > Date: Mon, 26 Aug 2013 15:06:10 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: drew.adams@oracle.com, lekktu@gmail.com, 15183@debbugs.gnu.org > > >> the attached patch should fix it but I don't have any idea how to > >> test it. > > > > Why, by committing it, of course. > > I checked in a slightly different fix. Thank you. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-08-26 13:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-25 1:01 bug#15183: 24.3.50; emacs_backtrace.txt Drew Adams 2013-08-25 1:51 ` Juanma Barranquero 2013-08-25 14:36 ` martin rudalics 2013-08-25 16:28 ` Drew Adams 2013-08-25 17:31 ` martin rudalics 2013-08-25 17:49 ` Eli Zaretskii 2013-08-26 13:06 ` martin rudalics 2013-08-26 13:34 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.