GNU bug report logs - #15183
24.3.50; emacs_backtrace.txt

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15183 in the body.
You can then email your comments to 15183 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; emacs_backtrace.txt
Date: Sat, 24 Aug 2013 18:01:34 -0700 (PDT)

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 <at> 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'

Message #8 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Sun, 25 Aug 2013 03:51:21 +0200

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

Message #11 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Drew Adams <drew.adams <at> oracle.com>, 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Sun, 25 Aug 2013 16:36:24 +0200

> 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

Message #14 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Juanma Barranquero <lekktu <at> gmail.com>
Cc: 15183 <at> debbugs.gnu.org
Subject: RE: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Sun, 25 Aug 2013 09:28:23 -0700 (PDT)

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.

Message #17 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Sun, 25 Aug 2013 19:31:20 +0200

[Message part 1 (text/plain, inline)]

> 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

[frame.c.diff (text/plain, inline)]

=== 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

Message #20 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, drew.adams <at> oracle.com, 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Sun, 25 Aug 2013 20:49:37 +0300

> Date: Sun, 25 Aug 2013 19:31:20 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, 15183 <at> 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.

Message #23 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, drew.adams <at> oracle.com, 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Mon, 26 Aug 2013 15:06:10 +0200

>> 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

Message #26 received at 15183 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, drew.adams <at> oracle.com, 15183 <at> debbugs.gnu.org
Subject: Re: bug#15183: 24.3.50; emacs_backtrace.txt
Date: Mon, 26 Aug 2013 16:34:04 +0300

> Date: Mon, 26 Aug 2013 15:06:10 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, lekktu <at> gmail.com, 15183 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.