[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26682: 26.0.50; Error at startup with minibuffer-only frame
From: |
Eli Zaretskii |
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@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.