GNU bug report logs - #48406
28.0.50; Emacs stuck in infinite loop in wait_reading_process_output when opening in fullscreen (NS)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48406 in the body.
You can then email your comments to 48406 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Emacs stuck in infinite loop in wait_reading_process_output
 when opening in fullscreen (NS)
Date: Thu, 13 May 2021 22:39:55 +0200

[Message part 1 (text/plain, inline)]

When starting with

    (push '(fullscreen . fullboth) default-frame-alist)

in early-init.el, apparently Emacs get stuck in an infinite loop after calling [EmacsView waitFullScreenTransition]. Please see the attached backtrace. I also tried moving that command around: in init.el, in emacs-startup-hook, all yield the same result. 

Toggling fullscreen after successful startup (by not trying to start in fullscreen) works ok. Also creating new frames with '(fullscreen . fullboth) in default-frame-alist works well.

Looks like this bug was introduced by bbc48b263485c26c6823eabdbbd7e9af62178e34

In GNU Emacs 28.0.50 (build 7, x86_64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241))
 of 2021-05-13 built on mbp2018.local
Repository revision: ff8bf8c8dfff2e4fc0fae50e3fcfcf3022bd0bb8
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1

Configured using:
 'configure --with-json --with-native-compilation --with-xwidgets
 CPPFLAGS=-I/usr/local/opt/llvm/include
 LDFLAGS=-L/usr/local/opt/llvm/lib'

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES
NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG THREADS TIFF
TOOLKIT_SCROLL_BARS XIM XWIDGETS ZLIB

[backtrace.txt (text/plain, attachment)]

Message #8 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Thu, 13 May 2021 22:15:56 +0100

On Thu, May 13, 2021 at 10:39:55PM +0200, Illia Ostapyshyn wrote:
> When starting with
> 
>     (push '(fullscreen . fullboth) default-frame-alist)
> 
> in early-init.el, apparently Emacs get stuck in an infinite loop
> after calling [EmacsView waitFullScreenTransition]. Please see the
> attached backtrace. I also tried moving that command around: in
> init.el, in emacs-startup-hook, all yield the same result.
> 
> Toggling fullscreen after successful startup (by not trying to start
> in fullscreen) works ok. Also creating new frames with '(fullscreen
> . fullboth) in default-frame-alist works well.
> 
> Looks like this bug was introduced by bbc48b263485c26c6823eabdbbd7e9af62178e34

Hmm, I don't know what's going on. I guess it's waiting on the
fullscreen transition before Emacs has started up fully and that's
causing a problem?

Andrii, any ideas?
-- 
Alan Third

Message #11 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 09:07:43 +0300

Alan Third <alan <at> idiocy.org> writes:

> On Thu, May 13, 2021 at 10:39:55PM +0200, Illia Ostapyshyn wrote:
>> When starting with
>> 
>>     (push '(fullscreen . fullboth) default-frame-alist)
>> 
>> in early-init.el, apparently Emacs get stuck in an infinite loop
>> after calling [EmacsView waitFullScreenTransition]. Please see the
>> attached backtrace. I also tried moving that command around: in
>> init.el, in emacs-startup-hook, all yield the same result.
>> 
>> Toggling fullscreen after successful startup (by not trying to start
>> in fullscreen) works ok. Also creating new frames with '(fullscreen
>> . fullboth) in default-frame-alist works well.
>> 
>> Looks like this bug was introduced by bbc48b263485c26c6823eabdbbd7e9af62178e34
>
> Hmm, I don't know what's going on. I guess it's waiting on the
> fullscreen transition before Emacs has started up fully and that's
> causing a problem?
>
> Andrii, any ideas?

I can't reproduce this.  Modifying the early-init.el file or executing
Emacs like this works fine for me:

emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"

But my OS and Emacs configuration is different:
System Description:  macOS 11.2.3
Configured using: 'configure --with-ns --with-rsvg'

Illia, please check if this small fix will help:

diff --git a/src/nsterm.m b/src/nsterm.m
index bb20886ab1..ef517098bf 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1640,8 +1640,6 @@ -(void)remove
          fullscreen also.  So skip handleFS as this will print an error.  */
       if ([view fsIsNative] && [view isFullscreen])
         {
-          // maybe it is not necessary to wait
-          [view waitFullScreenTransition];
           return;
         }

Message #14 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50;
 Emacs stuck in infinite loop in wait_reading_process_output when
 opening in fullscreen (NS)
Date: Fri, 14 May 2021 09:22:50 +0300

> From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
> Date: Thu, 13 May 2021 22:39:55 +0200
> 
> When starting with
> 
>     (push '(fullscreen . fullboth) default-frame-alist)
> 
> in early-init.el, apparently Emacs get stuck in an infinite loop after calling [EmacsView waitFullScreenTransition]. Please see the attached backtrace. I also tried moving that command around: in init.el, in emacs-startup-hook, all yield the same result. 

Why did you put that in early-init.el? why not in .emacs or init.el?

Message #17 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 11:13:13 +0200

Executing like this doesn't work for me:

    emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"

I've tried recompiling emacs with you configure flags, same result. Could it be the OS version? I doubt it, I recall having this issue long time ago, but I bore with it instead of reporting.

The patch didn't fix the issue, but there are two more instances of waitFullScreenTransition in nsterm.m. I narrowed it down to this one:

diff --git a/src/nsterm.m b/src/nsterm.m
index bb20886ab1..bf18ae48fa 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -8061,8 +8061,6 @@ - (void)toggleFullScreen: (id)sender
         {
 #endif
           [[self window] toggleFullScreen:sender];
-          // wait for fullscreen animation complete (bug#28496)
-          [self waitFullScreenTransition];
 #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
         }
 #endif

> I can't reproduce this.  Modifying the early-init.el file or executing
> Emacs like this works fine for me:
> 
> emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
> 
> But my OS and Emacs configuration is different:
> System Description:  macOS 11.2.3
> Configured using: 'configure --with-ns --with-rsvg'
> 
> Illia, please check if this small fix will help:
> 
> diff --git a/src/nsterm.m b/src/nsterm.m
> index bb20886ab1..ef517098bf 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -1640,8 +1640,6 @@ -(void)remove
>          fullscreen also.  So skip handleFS as this will print an error.  */
>       if ([view fsIsNative] && [view isFullscreen])
>         {
> -          // maybe it is not necessary to wait
> -          [view waitFullScreenTransition];
>           return;
>         }

Message #20 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 11:22:30 +0200

> On May 14, 2021, at 08:22, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
>> Date: Thu, 13 May 2021 22:39:55 +0200
>> 
>> When starting with
>> 
>>    (push '(fullscreen . fullboth) default-frame-alist)
>> 
>> in early-init.el, apparently Emacs get stuck in an infinite loop after calling [EmacsView waitFullScreenTransition]. Please see the attached backtrace. I also tried moving that command around: in init.el, in emacs-startup-hook, all yield the same result. 
> 
> Why did you put that in early-init.el? why not in .emacs or init.el?

I figured that way I wouldn't see an unconfigured frame for a fraction of a second when starting Emacs and it worked for me on other systems. Are there any caveats to it?

Like I mentioned, with this line in init.el Emacs exhibits the same behavior.

emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
doesn't work as well.

Message #23 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 13:55:24 +0300

> From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
> Date: Fri, 14 May 2021 11:22:30 +0200
> Cc: 48406 <at> debbugs.gnu.org
> 
> > On May 14, 2021, at 08:22, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
> >> Date: Thu, 13 May 2021 22:39:55 +0200
> >> 
> >> When starting with
> >> 
> >>    (push '(fullscreen . fullboth) default-frame-alist)
> >> 
> >> in early-init.el, apparently Emacs get stuck in an infinite loop after calling [EmacsView waitFullScreenTransition]. Please see the attached backtrace. I also tried moving that command around: in init.el, in emacs-startup-hook, all yield the same result. 
> > 
> > Why did you put that in early-init.el? why not in .emacs or init.el?
> 
> I figured that way I wouldn't see an unconfigured frame for a fraction of a second when starting Emacs and it worked for me on other systems. Are there any caveats to it?

Yes, the caveat is that you do this too early.  I'm not sure I want to
tweak Emacs to support these settings in early-init.el just to avoid
the momentary display of the original frame.  As documented,
early-init.el is for stuff that _must_ be there, or else it won't
work at all.

> Like I mentioned, with this line in init.el Emacs exhibits the same behavior.
> 
> emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
> doesn't work as well.

"Doesn't work" in what sense?  What did you expect to happen and what
did indeed happen?

And the above line is definitely not for init.el, it's a command for
invoking Emacs from the shell prompt.  So I'm not sure I understand
what exactly did you try with that command.

Message #26 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 13:09:47 +0200

> On May 14, 2021, at 12:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Like I mentioned, with this line in init.el Emacs exhibits the same behavior.
>> 
>> emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
>> doesn't work as well.
> 
> "Doesn't work" in what sense?  What did you expect to happen and what
> did indeed happen?
> 
> And the above line is definitely not for init.el, it's a command for
> invoking Emacs from the shell prompt.  So I'm not sure I understand
> what exactly did you try with that command.

Did not work in the sense of resolving the original issue of this bug
report:

Invoking (push '(fullscreen . fullboth) default-frame-alist) during
Emacs startup causes it to hang, no matter where it is, early-init.el,
init.el or passed through --execute. Same goes for
(toggle-frame-fullscreen) and everything else that makes Emacs switch
to fullscreen mode.

Message #29 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 14:13:45 +0300

> From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
> Date: Fri, 14 May 2021 13:09:47 +0200
> Cc: 48406 <at> debbugs.gnu.org
> 
> > On May 14, 2021, at 12:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> Like I mentioned, with this line in init.el Emacs exhibits the same behavior.
> >> 
> >> emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
> >> doesn't work as well.
> > 
> > "Doesn't work" in what sense?  What did you expect to happen and what
> > did indeed happen?
> > 
> > And the above line is definitely not for init.el, it's a command for
> > invoking Emacs from the shell prompt.  So I'm not sure I understand
> > what exactly did you try with that command.
> 
> Did not work in the sense of resolving the original issue of this bug
> report:
> 
> Invoking (push '(fullscreen . fullboth) default-frame-alist) during
> Emacs startup causes it to hang, no matter where it is, early-init.el,
> init.el or passed through --execute. Same goes for
> (toggle-frame-fullscreen) and everything else that makes Emacs switch
> to fullscreen mode.

If this fails in init.el, then we should fix that.  But I don't
promise the fix will make it work in early-init.el.

Message #32 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 22:32:56 +0300

Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com> writes:

> Executing like this doesn't work for me:
>
>     emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
>
> I've tried recompiling emacs with you configure flags, same
> result. Could it be the OS version? I doubt it, I recall having this
> issue long time ago, but I bore with it instead of reporting.

Well, I'm on macOS 11.3.1 now, recompiled Emacs with `make bootstrap`
still works fine.

> The patch didn't fix the issue, but there are two more instances of
> waitFullScreenTransition in nsterm.m. I narrowed it down to this one:
>
> @@ -8061,8 +8061,6 @@ - (void)toggleFullScreen: (id)sender
>          {
>  #endif
>            [[self window] toggleFullScreen:sender];
> -          // wait for fullscreen animation complete (bug#28496)
> -          [self waitFullScreenTransition];

This one is needed to avoid `(sleep-for 0.5)` in `frame.el`.

Maybe we need more users affected by this bug to find out the conditions for
reproducing this error.

Can you please enable NSTRACE by uncomenting this line in the
`src/nsterm.h` file:

/* #define NSTRACE_ENABLED 1          */

Hope trace messages will give us some more information on what is going
on.


-- 
Andrii

Message #35 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Fri, 14 May 2021 21:34:42 +0100

On Fri, May 14, 2021 at 10:32:56PM +0300, Andrii Kolomoiets wrote:
> Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com> writes:
> 
> > Executing like this doesn't work for me:
> >
> >     emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
> >
> > I've tried recompiling emacs with you configure flags, same
> > result. Could it be the OS version? I doubt it, I recall having this
> > issue long time ago, but I bore with it instead of reporting.
> 
> Well, I'm on macOS 11.3.1 now, recompiled Emacs with `make bootstrap`
> still works fine.

Now I've dug out my Mac I can confirm I see this hang as well.

The problem is that we never reach the NS run loop and therefore
windowDidEnterFullScreen is never called.

It appears ns_select returns in this code:

  if (hold_event_q.nr > 0)
    {
      /* We already have events pending.  */
      raise (SIGIO);
      errno = EINTR;
      return -1;
    }

hmmmm.......

This fixes it for me, but whether it's a good idea or not I don't know:

modified   src/nsterm.m
@@ -7876,6 +7876,7 @@ - (void)windowDidEnterFullScreen:(NSNotification *)notification
   NSTRACE ("[EmacsView windowDidEnterFullScreen:]");
   [self windowDidEnterFullScreen];
   in_fullscreen_transition = NO;
+  ns_send_appdefined (-1);
 }
 
 - (void)windowDidEnterFullScreen /* provided for direct calls */
@@ -7935,6 +7936,7 @@ - (void)windowDidExitFullScreen:(NSNotification *)notification
   NSTRACE ("[EmacsView windowDidExitFullScreen:]");
   [self windowDidExitFullScreen];
   in_fullscreen_transition = NO;
+  ns_send_appdefined (-1);
 }
 
 - (void)windowDidExitFullScreen /* provided for direct calls */
@@ -7974,7 +7976,7 @@ - (void)waitFullScreenTransition
   while ([self inFullScreenTransition])
     {
       NSTRACE ("wait for fullscreen");
-      wait_reading_process_output (0, 300000000, 0, 1, Qnil, NULL, 0);
+      [NSApp run];
     }
 #endif
 }

-- 
Alan Third

Message #38 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, Alan Third <alan <at> idiocy.org>,
 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 15 May 2021 01:53:55 +0300

On 14/05/2021 22:32 +0300, Andrii Kolomoiets wrote:

> Maybe we need more users affected by this bug to find out the conditions for
> reproducing this error.

I've reported a similar bug#41055 a year ago (and can reproduce now).

Filipp

Message #41 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 48406 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 15 May 2021 10:34:44 +0200

[Message part 1 (text/plain, inline)]

> Now I've dug out my Mac I can confirm I see this hang as well.
> 
> The problem is that we never reach the NS run loop and therefore
> windowDidEnterFullScreen is never called.
> 
> It appears ns_select returns in this code:
> 
>   if (hold_event_q.nr > 0)
>     {
>       /* We already have events pending.  */
>       raise (SIGIO);
>       errno = EINTR;
>       return -1;
>     }
> 
> hmmmm.......
> 
> This fixes it for me, but whether it's a good idea or not I don't know:

I can confirm that the patch has worked for me as well.

As Andrii suggested, I'm attaching the output produced by nstrace (without the patch)

[nstrace.txt (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

Message #46 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 15 May 2021 22:44:28 +0300

Alan Third <alan <at> idiocy.org> writes:

> Now I've dug out my Mac I can confirm I see this hang as well.
>
> The problem is that we never reach the NS run loop and therefore
> windowDidEnterFullScreen is never called.
>
> This fixes it for me, but whether it's a good idea or not I don't know:
>
> -      wait_reading_process_output (0, 300000000, 0, 1, Qnil, NULL, 0);
> +      [NSApp run];

I really like this change.  Using `wait_reading_process_output` to wait
for NS event was a bad idea.

Though I don't understand why my setup isn't affected by this bug.

Alan, please install your patch.

Thanks!

Message #49 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 15 May 2021 23:47:18 +0100

On Sat, May 15, 2021 at 10:44:28PM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> > Now I've dug out my Mac I can confirm I see this hang as well.
> >
> > The problem is that we never reach the NS run loop and therefore
> > windowDidEnterFullScreen is never called.
> >
> > This fixes it for me, but whether it's a good idea or not I don't know:
> >
> > -      wait_reading_process_output (0, 300000000, 0, 1, Qnil, NULL, 0);
> > +      [NSApp run];
> 
> I really like this change.  Using `wait_reading_process_output` to wait
> for NS event was a bad idea.
> 
> Though I don't understand why my setup isn't affected by this bug.

I can only guess that for some reason your setup doesn't have these
pending inputs that block ns_select. But even so I don't really
understand what's going on as I thought if there were pending inputs
then ns_read_socket would be called and clear them...

> Alan, please install your patch.

You know, I'm probably being stupid, but I can't for the life of me
remember why we need to wait for the fullscreen transition to
complete. I *thought* it was because we had a crash if we didn't, but
if I remove the wait it all works just fine...

It could be that it's pure chance I'm not seeing any problems, or that
some other fix has fixed the crash, or that the older drawing scheme
used before 10.14 has a problem and the new one doesn't... Or
something else. Do you have any idea?

I *do* remember that there was a pause required for the non-native
fullscreen due to a crash, and I don't think that will have changed,
except that I don't think I've heard from anyone still using 10.6 for
a couple of years now.
-- 
Alan Third

Message #52 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sun, 16 May 2021 23:09:39 +0300

Alan Third <alan <at> idiocy.org> writes:

> You know, I'm probably being stupid, but I can't for the life of me
> remember why we need to wait for the fullscreen transition to
> complete. I *thought* it was because we had a crash if we didn't, but
> if I remove the wait it all works just fine...

Same here.  The code snippets provided in Bug#28496 and Bug#36672 are
works fine.

> It could be that it's pure chance I'm not seeing any problems, or that
> some other fix has fixed the crash,

Yes, the NS port certainly made a good progress, thank you :)

> or that the older drawing scheme used before 10.14 has a problem and
> the new one doesn't... Or something else. Do you have any idea?

This is the only example that comes to my mind for now:

(progn
  (toggle-frame-fullscreen)
  (toggle-frame-fullscreen))

Though code like this is not widely used (hope so), it's still some kind
of unexpected behavior.

> I *do* remember that there was a pause required for the non-native
> fullscreen due to a crash, and I don't think that will have changed,
> except that I don't think I've heard from anyone still using 10.6 for
> a couple of years now.

Well, we can pause for the non-native fullscreen users.


-- 
Andrii

Message #55 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Wed, 26 May 2021 21:26:39 +0100

On Sun, May 16, 2021 at 11:09:39PM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> > You know, I'm probably being stupid, but I can't for the life of me
> > remember why we need to wait for the fullscreen transition to
> > complete. I *thought* it was because we had a crash if we didn't, but
> > if I remove the wait it all works just fine...
> 
> Same here.  The code snippets provided in Bug#28496 and Bug#36672 are
> works fine.

I'm really inclined to try removing it and seeing if anyone complains.
I don't think they will.

> > or that the older drawing scheme used before 10.14 has a problem and
> > the new one doesn't... Or something else. Do you have any idea?
> 
> This is the only example that comes to my mind for now:
> 
> (progn
>   (toggle-frame-fullscreen)
>   (toggle-frame-fullscreen))
> 
> Though code like this is not widely used (hope so), it's still some kind
> of unexpected behavior.

Hah, I was expecting it to crash, but it's very well behaved! :)

I guess we could check whether we're already in a fullscreen
transition, and if so schedule another call to happen later on... I'm
not sure if it's really necessary though.

> > I *do* remember that there was a pause required for the non-native
> > fullscreen due to a crash, and I don't think that will have changed,
> > except that I don't think I've heard from anyone still using 10.6 for
> > a couple of years now.
> 
> Well, we can pause for the non-native fullscreen users.

Good news, as far as I can see the pause is no longer required! It's
in ns_fullscreen_hook, so if you remove that and all the other pauses
too, we can try pushing it up to master. (See bug#28443.)
-- 
Alan Third

Message #58 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Wed, 26 May 2021 21:28:38 +0100

On Wed, May 26, 2021 at 09:26:39PM +0100, Alan Third wrote:
> 
> > > I *do* remember that there was a pause required for the non-native
> > > fullscreen due to a crash, and I don't think that will have changed,
> > > except that I don't think I've heard from anyone still using 10.6 for
> > > a couple of years now.
> > 
> > Well, we can pause for the non-native fullscreen users.
> 
> Good news, as far as I can see the pause is no longer required! It's
> in ns_fullscreen_hook, so if you remove that and all the other pauses
> too, we can try pushing it up to master. (See bug#28443.)

Actually, no, it's still needed for now, but it doesn't have any
effect on the rest, so please, if you want to remove all the pauses
(except the non-native one) we can try it out.
-- 
Alan Third

Message #61 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>, 48406 <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 5 Jun 2021 14:45:38 +0100

[Message part 1 (text/plain, inline)]

Patch attached.

I think this is probably pretty safe, but I'll leave it a couple of
days in case someone finds a problem with it.
-- 
Alan Third

[0001-Remove-pause-on-fullscreening-in-NS-bug-48406.patch (text/plain, attachment)]

Message #64 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 48406 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 5 Jun 2021 18:21:59 +0200

[Message part 1 (text/plain, inline)]

> On Jun 5, 2021, at 15:45, Alan Third <alan <at> idiocy.org> wrote:
> 
> Patch attached.
> 
> I think this is probably pretty safe, but I'll leave it a couple of
> days in case someone finds a problem with it.
> -- 
> Alan Third
> <0001-Remove-pause-on-fullscreening-in-NS-bug-48406.patch>

Hello Alan,

thank you for working on this. I am going to apply this patch and report any
possible issues with it. I commented out that problematic pause for fullscreen
transition myself just after starting this thread and didn’t encounter any
issues so far.

By the way, there seems to be a compilation issue as not all references to
in_fullscreen_transition were removed (see attachment).

[0001-remove-in_fullscreen_transition-references.patch (application/octet-stream, attachment)]

Message #67 received at 48406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>
Cc: 48406 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Sat, 5 Jun 2021 17:33:49 +0100

[Message part 1 (text/plain, inline)]

On Sat, Jun 05, 2021 at 06:21:59PM +0200, Illia Ostapyshyn wrote:
> 
> By the way, there seems to be a compilation issue as not all references to
> in_fullscreen_transition were removed (see attachment).

Oops, my mistake. Please use the attached patch instead.
-- 
Alan Third

[v2-0001-Remove-pause-on-fullscreening-in-NS-bug-48406.patch (text/plain, attachment)]

Message #72 received at 48406-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Illia Ostapyshyn <ilya.ostapyshyn <at> gmail.com>,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>, 48406-done <at> debbugs.gnu.org
Subject: Re: bug#48406: 28.0.50; Emacs stuck in infinite loop in
 wait_reading_process_output when opening in fullscreen (NS)
Date: Wed, 9 Jun 2021 22:01:34 +0100

On Sat, Jun 05, 2021 at 05:33:49PM +0100, Alan Third wrote:
> On Sat, Jun 05, 2021 at 06:21:59PM +0200, Illia Ostapyshyn wrote:
> > 
> > By the way, there seems to be a compilation issue as not all references to
> > in_fullscreen_transition were removed (see attachment).
> 
> Oops, my mistake. Please use the attached patch instead.

Since I've not heard anything back from anyone I've pushed this to
master. If there still are any problems, please reply and we can
reopen the bug report.
-- 
Alan Third

Previous Next

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