GNU bug report logs - #26682
26.0.50; Error at startup with minibuffer-only frame

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 26682 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: bug#26682: 26.0.50; Error at startup with minibuffer-only frame
Date: Sat, 29 Apr 2017 13:36:01 +0300

> Date: Sat, 29 Apr 2017 12:30:39 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 26682 <at> 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.

Previous Next

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