bug#26682: 26.0.50; Error at startup with minibuffer-only frame

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Stefan Monnier]

Some recent change in `master` has introduced a regression when using my
configuration.  I can reproduce it with the recipe below:

    src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . only))))'

This launches Emacs but signals an error "Attempt to delete the only
frame".


        Stefan



In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-04-27 built on lechazo
Repository revision: 79c5ea9911a9aba7db0ba0e367e06507cee2fc02
Windowing system distributor 'The X.Org Foundation', version 11.0.11901000
System Description:	Debian GNU/Linux 9.0 (stretch)

Recent messages:
Entering debugger...
Continuing.
Error: (error "Unable to activate package ‘ess’.
Required package ‘julia-mode-0.3’ is unavailable")
Loading /home/monnier/src/elisp/ProofGeneral/generic/proof-site.el (source)...done
Loading /home/monnier/etc/emacs/X11.el (source)...done
Loading /home/monnier/etc/emacs/custom.el (source)...done
Source file ‘/home/monnier/src/emacs/elpa/packages/load-dir/load-dir.el’ newer than byte-compiled file
Starting new Ispell process /usr/bin/aspell with american dictionary...
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure -C --enable-checking --with-modules --enable-check-lisp-object-type
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG SOUND GPM DBUS GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11
MODULES

Important settings:
  value of $LANG: fr_CH.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  outline-minor-mode: t
  flyspell-mode: t
  checkdoc-minor-mode: t
  electric-pair-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  url-handler-mode: t
  cl-old-struct-compat-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-mode: t
  prettify-symbols-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/monnier/src/emacs/elpa/packages/svg/svg hides /home/monnier/src/emacs/trunk/lisp/svg
/home/monnier/src/emacs/elpa/packages/landmark/landmark hides /home/monnier/src/emacs/trunk/lisp/obsolete/landmark

Features:
(shadow sort mail-extr emacsbug message subr-x puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils noutline outline easy-mmode flyspell
ispell checkdoc thingatpt load-dir elec-pair reveal autoinsert
proof-site proof-autoloads cl pg-vars savehist minibuf-eldef disp-table
help-mode debug advice info realgud-recursive-autoloads finder-inf
url-auth package easymenu epg-config url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars
seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs pcase cl-lib
bbdb-loaddefs time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 144878 7559)
 (symbols 24 23944 1)
 (miscs 20 71 182)
 (strings 16 37557 5283)
 (string-bytes 1 1279263)
 (vectors 8 19171)
 (vector-slots 4 545328 4402)
 (floats 8 68 266)
 (intervals 28 307 0)
 (buffers 520 12))

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 27 Apr 2017 13:08:10 -0400
> 
> 
> Some recent change in `master` has introduced a regression when using my
> configuration.  I can reproduce it with the recipe below:
> 
>     src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . only))))'
> 
> This launches Emacs but signals an error "Attempt to delete the only
> frame".

This seems to come from the following part at the beginning of
delete_frame:

  else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force)))
    {
      if (NILP (force))
	error ("Attempt to delete the sole visible or iconified frame");
      else
	error ("Attempt to delete the only frame");
    }

The original code there was:

  if (NILP (force) && !other_visible_frames (f))
    error ("Attempt to delete the sole visible or iconified frame");

Martin, why did you decide to disallow frame deletion when the FORCE
argument is t?  This makes delete-frame violate its documented
contract, whereby if FORCE == Qt, the fact that other frames are not
visible doesn't count.

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 6005 bytes --]

 > This seems to come from the following part at the beginning of
 > delete_frame:
 >
 >    else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force)))
 >      {
 >        if (NILP (force))
 > 	error ("Attempt to delete the sole visible or iconified frame");
 >        else
 > 	error ("Attempt to delete the only frame");
 >      }
 >
 > The original code there was:
 >
 >    if (NILP (force) && !other_visible_frames (f))
 >      error ("Attempt to delete the sole visible or iconified frame");
 >
 > Martin, why did you decide to disallow frame deletion when the FORCE
 > argument is t?  This makes delete-frame violate its documented
 > contract, whereby if FORCE == Qt, the fact that other frames are not
 > visible doesn't count.

I probably was confused.  One problem I wanted to fix is the following
scenario with Emacs 25.2: With emacs -Q evaluate the following four
forms in row:

(defvar old-frame (selected-frame))

(defvar new-frame (make-frame))

(add-hook 'delete-frame-functions
	  (lambda (f) (delete-frame new-frame)))

(delete-frame old-frame)

This gets me here:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c911231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c911231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1  0x012d28dd in emacs_abort () at w32fns.c:9830
#2  0x01323e14 in w32_reset_fringes () at fringe.c:1777
#3  0x012f1489 in x_delete_display (dpyinfo=0x2b1bc60) at w32term.c:6941
#4  0x012f1247 in x_delete_terminal (terminal=0x1a560b0) at w32term.c:6847
#5  0x01130bbe in Fdelete_terminal (terminal=..., force=...) at terminal.c:390
#6  0x01019d9c in delete_frame (frame=..., force=...) at frame.c:1731
#7  0x0101a55f in Fdelete_frame (frame=..., force=...) at frame.c:1842
#8  0x0121f0c2 in eval_sub (form=...) at eval.c:2174
#9  0x0121e235 in Feval (form=..., lexical=...) at eval.c:1993
#10 0x0122109f in Ffuncall (nargs=3, args=0x82e0e8) at eval.c:2701
#11 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82e690) at bytecode.c:880
#12 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82e688) at eval.c:2860
#13 0x0122146e in Ffuncall (nargs=2, args=0x82e680) at eval.c:2747
#14 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82ed78) at bytecode.c:880
#15 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82ed70) at eval.c:2860
#16 0x0122146e in Ffuncall (nargs=2, args=0x82ed68) at eval.c:2747
#17 0x01213432 in Ffuncall_interactively (nargs=2, args=0x82ed68) at callint.c:252
#18 0x01220f0f in Ffuncall (nargs=3, args=0x82ed60) at eval.c:2678
#19 0x0121665e in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:843
#20 0x012210f6 in Ffuncall (nargs=4, args=0x82f1c8) at eval.c:2705
#21 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f780) at bytecode.c:880
#22 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f778) at eval.c:2860
#23 0x0122146e in Ffuncall (nargs=2, args=0x82f770) at eval.c:2747
#24 0x012207bf in call1 (fn=..., arg1=...) at eval.c:2557
#25 0x01151cff in command_loop_1 () at keyboard.c:1479
#26 0x0121bd32 in internal_condition_case (bfun=0x1151233 <command_loop_1>, handlers=..., hfun=0x11504cb <cmd_error>) at eval.c:1314
#27 0x01150ccd in command_loop_2 (ignore=...) at keyboard.c:1107
#28 0x0121aed6 in internal_catch (tag=..., func=0x1150c91 <command_loop_2>, arg=...) at eval.c:1079
#29 0x01150c53 in command_loop () at keyboard.c:1086
#30 0x0114fee3 in recursive_edit_1 () at keyboard.c:692
#31 0x011501a4 in Frecursive_edit () at keyboard.c:763
#32 0x0114d8ba in main (argc=2, argv=0xa32658) at emacs.c:1626

Lisp Backtrace:
"delete-frame" (0x82ded0)
"eval" (0x82e0f0)
"elisp--eval-last-sexp" (0x82e688)
"eval-last-sexp" (0x82ed70)
"funcall-interactively" (0x82ed68)
"call-interactively" (0x82f1d0)
"command-execute" (0x82f778)

Admittedly calling ‘delete-frame’ from ‘delete-frame-functions’ is not
nice.  But with child frames and the ‘delete-before’ parameter it would
be easy to get a similar crash with a less provocative setup.

So I started to check for the existence of other frames twice and be
more rigorous.  Too rigorous, as Stefan's scenario demonstrates.

I attach a presumptive patch which should handle Stefan's setup and also
a few ‘make-frame-invisible’ calls which were not handled correctly.
Please try it.  It needs some further testing before I can commit it.

As a matter of fact, I was not able to repeat Stefan's scenario on
GNU/Linux - the initial frame was always deleted orderly.  But the
behavior is easily reproducible on Windows.  On Windows, however, even
with my patch, one out of ten times starting Emacs with Stefan's command
line hangs it with the initial frame visible and I have to quit with
C-g.

More precisely, it hangs in ‘frame-notice-user-settings’ in the while
loop below

	    ;; MS-Windows needs this to avoid inflooping below.
	    (if (eq system-type 'windows-nt)
		(sit-for 0 t))
	    ;; If the frame isn't visible yet, wait till it is.
	    ;; If the user has to position the window,
	    ;; Emacs doesn't know its real position until
	    ;; the frame is seen to be visible.
	    (while (not (cdr (assq 'visibility
				   (frame-parameters frame-initial-frame))))
	      (sleep-for 1))

and it does so always when I run Emacs under GDB.  I don't yet know why
it hangs: The request to make the frame visible is posted orderly but
somehow SET_FRAME_VISIBLE gets never executed.  Can you reproduce it?


Note also that the patch restores the Emasc 25.2 behavior where deleting
the last minibuffer frame with a mouse click raises the "surrogate ..."
error.  My earlier changes did ‘save-buffers-kill-emacs’ in that case.

martin

[-- Attachment #2: frame.c.el.diff --]
[-- Type: text/plain, Size: 4834 bytes --]

diff --git a/lisp/frame.el b/lisp/frame.el
index cec2624..8dad63f 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -123,8 +123,6 @@ handle-delete-frame
             ;; not a child frame.
             (when (and (not (eq frame-1 frame))
                        (frame-visible-p frame-1)
-                       (window-live-p (minibuffer-window frame-1))
-                       (eq (window-frame (minibuffer-window frame-1)) frame-1)
                        (not (frame-parent frame-1))
                        (not (frame-parameter frame-1 'delete-before)))
               (throw 'other-frame t))))
diff --git a/src/frame.c b/src/frame.c
index 681a245..b108e45 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1560,15 +1560,16 @@ of them (the selected terminal frame) is actually displayed.
  * Return true if there exists at least one visible or iconified frame
  * but F.  Return false otherwise.
  *
- * Always return false when all remaining frames are either tooltip or
- * child frames or frames with a non-nil `delete-before' parameter.  If
- * INVISIBLE is false, also return false when the minibuffer window of
- * all remaining frames is on F.
-
+ * INVISIBLE true means we are called from make_frame_invisible where
+ * such a frame must be visible or iconified.  INVISIBLE nil means we
+ * are called from delete_frame.  In that case FORCE true means that the
+ * visibility status of such a frame can be ignored.
+ *
  * If F is the terminal frame and we are using X, return true if at
- * least one X frame exists.  */
+ * least one X frame exists.
+ */
 static bool
-other_frames (struct frame *f, bool invisible)
+other_frames (struct frame *f, bool invisible, bool force)
 {
   Lisp_Object frames, frame, frame1;
   struct frame *f1;
@@ -1591,23 +1592,20 @@ of them (the selected terminal frame) is actually displayed.
 	    x_sync (f1);
 #endif
 	  if (NILP (Fframe_parameter (frame1, Qtooltip))
-	      /* Tooltips and child frames don't count.  */
+	      /* Tooltips and child frames count neither for
+		 invisibility nor for deletions.  */
 	      && !FRAME_PARENT_FRAME (f1)
 	      /* Frames with a non-nil `delete-before' parameter don't
-		 count - either they depend on us or they depend on a
-		 frame that we will have to find right here.  */
-	      && NILP (get_frame_param (f1, Qdelete_before))
-	      /* Frames whose minibuffer window is on F don't count
-		 unless INVISIBLE is set - in that case F is either made
-		 invisible and may be autoraised from such a frame or
-		 the FORCE argument of delete_frame was non-nil.  */
-	      && (invisible || NILP (minibuffer_window)
-		  || !EQ (FRAME_MINIBUF_WINDOW (f1), minibuffer_window))
-	      /* At least one visible/iconified frame must remain.  */
+		 count for deletions.  */
+	      && (invisible || NILP (get_frame_param (f1, Qdelete_before)))
+	      /* For invisibility and normal deletions, at least one
+		 visible or iconified frame must remain (Bug#26682).  */
 	      && (FRAME_VISIBLE_P (f1) || FRAME_ICONIFIED_P (f1)
-		  /* Allow deleting the terminal frame when at least one
-		     X frame exists.  */
-		  || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f))))
+		  || (!invisible
+		      && (force
+			  /* Allow deleting the terminal frame when at
+			     least one X frame exists.  */
+			  || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f))))))
 	    return true;
 	}
     }
@@ -1680,7 +1678,7 @@ of them (the selected terminal frame) is actually displayed.

   if (!FRAME_LIVE_P (f))
     return Qnil;
-  else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force)))
+  else if (!EQ (force, Qnoelisp) && !other_frames (f, false, true))
     {
       if (NILP (force))
 	error ("Attempt to delete the sole visible or iconified frame");
@@ -1752,7 +1750,7 @@ of them (the selected terminal frame) is actually displayed.
      one.  */
   if (!FRAME_LIVE_P (f))
     return Qnil;
-  else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force)))
+  else if (!EQ (force, Qnoelisp) && !other_frames (f, false, true))
     {
       if (NILP (force))
 	error ("Attempt to delete the sole visible or iconified frame");
@@ -2275,7 +2273,7 @@ of them (the selected terminal frame) is actually displayed.
 {
   struct frame *f = decode_live_frame (frame);

-  if (NILP (force) && !other_frames (f, true))
+  if (NILP (force) && !other_frames (f, true, false))
     error ("Attempt to make invisible the sole visible or iconified frame");

   /* Don't allow minibuf_window to remain on an invisible frame.  */
@@ -2878,6 +2876,9 @@ Each element of ALIST has the form (PARM . VALUE), where PARM is a symbol.
   struct frame *f = decode_live_frame (frame);
   Lisp_Object prop, val;

+  if (EQ (alist, Qt))
+    return Qnil;
+
   /* I think this should be done with a hook.  */
 #ifdef HAVE_WINDOW_SYSTEM
   if (FRAME_WINDOW_P (f))

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Stefan Monnier]

> I attach a presumptive patch which should handle Stefan's setup and also
> a few ‘make-frame-invisible’ calls which were not handled correctly.
> Please try it.  It needs some further testing before I can commit it.

It seems to fix the problem.  I haven't yet seen any obvious problem
with it.  IOW so far so good,


        Stefan

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[martin rudalics]

 > On Windows, however, even
 > with my patch, one out of ten times starting Emacs with Stefan's command
 > line hangs it with the initial frame visible and I have to quit with
 > C-g.
 >
 > More precisely, it hangs in ‘frame-notice-user-settings’ in the while
 > loop below
 >
 >          ;; MS-Windows needs this to avoid inflooping below.
 >          (if (eq system-type 'windows-nt)
 >          (sit-for 0 t))
 >          ;; If the frame isn't visible yet, wait till it is.
 >          ;; If the user has to position the window,
 >          ;; Emacs doesn't know its real position until
 >          ;; the frame is seen to be visible.
 >          (while (not (cdr (assq 'visibility
 >                     (frame-parameters frame-initial-frame))))
 >            (sleep-for 1))
 >
 > and it does so always when I run Emacs under GDB.  I don't yet know why
 > it hangs: The request to make the frame visible is posted orderly but
 > somehow SET_FRAME_VISIBLE gets never executed.  Can you reproduce it?

FYI it's caused by WM_MOVE which OT1H is likely counted by the

     for (count = input_signal_count + 10;
	 input_signal_count < count && !FRAME_VISIBLE_P (f);)

loop in x_make_frame_visible and OTOH lacks a SET_FRAME_VISIBLE (f, 1).

martin

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Eli Zaretskii]

> Date: Sat, 29 Apr 2017 12:30:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 26682@debbugs.gnu.org
> 
>  > On Windows, however, even
>  > with my patch, one out of ten times starting Emacs with Stefan's command
>  > line hangs it with the initial frame visible and I have to quit with
>  > C-g.
>  >
>  > More precisely, it hangs in ‘frame-notice-user-settings’ in the while
>  > loop below
>  >
>  >          ;; MS-Windows needs this to avoid inflooping below.
>  >          (if (eq system-type 'windows-nt)
>  >          (sit-for 0 t))
>  >          ;; If the frame isn't visible yet, wait till it is.
>  >          ;; If the user has to position the window,
>  >          ;; Emacs doesn't know its real position until
>  >          ;; the frame is seen to be visible.
>  >          (while (not (cdr (assq 'visibility
>  >                     (frame-parameters frame-initial-frame))))
>  >            (sleep-for 1))
>  >
>  > and it does so always when I run Emacs under GDB.  I don't yet know why
>  > it hangs: The request to make the frame visible is posted orderly but
>  > somehow SET_FRAME_VISIBLE gets never executed.  Can you reproduce it?
> 
> FYI it's caused by WM_MOVE which OT1H is likely counted by the
> 
>      for (count = input_signal_count + 10;
> 	 input_signal_count < count && !FRAME_VISIBLE_P (f);)
> 
> loop in x_make_frame_visible and OTOH lacks a SET_FRAME_VISIBLE (f, 1).

I think Stefan's command line has a race condition, that's why it
sometimes hangs.

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[martin rudalics]

 > I think Stefan's command line has a race condition, that's why it
 > sometimes hangs.

I'm still not entirely sure about what happened but not making a move
frame event when the frame is invisible seems to cure it.  The entire
input_signal_count rigmarole was removed from xterm.c some time ago, so
maybe we should do the same for w32term.c but I have no real idea why it
was needed in the first place so I'll rather refrain from doing that.

martin

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[martin rudalics]

 > It seems to fix the problem.  I haven't yet seen any obvious problem
 > with it.  IOW so far so good,

I installed a slightly different version now.  If you don't see any
problems, please close this bug.

Thanks, martin

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Eli Zaretskii]

> Date: Sun, 30 Apr 2017 10:32:03 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@IRO.UMontreal.CA, 26682@debbugs.gnu.org
> 
> The entire input_signal_count rigmarole was removed from xterm.c
> some time ago, so maybe we should do the same for w32term.c but I
> have no real idea why it was needed in the first place so I'll
> rather refrain from doing that.

This was removed from xterm.c due to real problems, so let's wait for
similar reasons, if they come, before we remove this from w32term.c.

bug#26682: 26.0.50; Error at startup with minibuffer-only frame

[Stefan Monnier]

>> It seems to fix the problem.  I haven't yet seen any obvious problem
>> with it.  IOW so far so good,
> I installed a slightly different version now.  If you don't see any
> problems, please close this bug.

Thanks, seems to do the trick here, closing,


        Stefan