Subject: bug#15183: 24.3.50; emacs_backtrace.txt

From: martin rudalics <[email-masked]>
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