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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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