GNU bug report logs - #72496
31.0.50; macOS: freezes without beach ball

Previous Next

To reply to this bug, email your comments to 72496 AT debbugs.gnu.org.

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

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; macOS: freezes without beach ball
Date: Tue, 06 Aug 2024 15:39:43 +0200

In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin23.6.0, NS
 appkit-2487.70 Version 14.6 (Build 23G80)) of 2024-08-05 built on
 pro2.fritz.box
Repository revision: c7d9cd722e5a7042a52c92f8497f903bfe9870b8

This is one of the problems on macOS that I'm experiencing quite
often. I have no idea what is causing this, and I haven't found a way
to make it reproducible. I guess I should file a bug report anyway.

Let me first try to describe briefly how NS GUI event handling works
in Emacs.

The whole story starts with get_input_pending which calls gobble_input
which calls a terminal's read_socket_hook, which is ns_read_socket in
macOS. ns_read_socket calls [NSApplication run] to process macOS GUI
events.

The problem starts with [NSApplication run] being an endless loop that
gets the next event, and dispatches it by calling the application's
sendEvent method. The only way to make the run loop terminate is by
calling [NSApplication stop]. This sets a flag that [NSApplicatoin
run] is supposed to check and then return, so that we eventually
return to ns_read_socket.

We call [NSApplicaton stop] in our [EmacsApp sendEvent] method. To get
there, we post special application-defined events to the application
which [NSApplication run] processes and dispatches via sendEvent which
calls stop and makes [NSApplication run] return to its caller. Note
that stop only sets a flag, so we need to process another event to
make run terminate. That's at least my understanding.

We are posting these events all over the place, not only before
ns_read_socket calls [NSApplication run]. And, to complicate matters,
whether or not ns_send_appdefined actually posts an event depends on a
global boolean variable. IOW, it's impenetrable.

(I'm also leaving out the generation of input_events for Emacs here,
which is another can of worms.)

Problem is that this not always works. More specifically, this code in
ns_read_socket_1

          /* Run and wait for events.  We must always send one NX_APPDEFINED event
             to ourself, otherwise [NXApp run] will never exit.  */
          send_appdefined = YES;
          ns_send_appdefined (-1);

          [NSApp run];

gets stuck in the GUI event loop, and the last line never returns. The
effect being that Emacs freezes without a beach ball of death. It
processes Cocoa events but Emacs never sees any input_events.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Tue, 06 Aug 2024 17:53:17 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Tue, 06 Aug 2024 15:39:43 +0200
> 
> We call [NSApplicaton stop] in our [EmacsApp sendEvent] method. To get
> there, we post special application-defined events to the application
> which [NSApplication run] processes and dispatches via sendEvent which
> calls stop and makes [NSApplication run] return to its caller.

Is there any way to initiate posting that "special application-defined
event" when Emacs is stuck thusly?  For example, from some system
signal-like event, or from a debugger?  Then you at least would have a
fire escape.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Tue, 06 Aug 2024 18:36:39 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Tue, 06 Aug 2024 15:39:43 +0200
>> 
>> We call [NSApplicaton stop] in our [EmacsApp sendEvent] method. To get
>> there, we post special application-defined events to the application
>> which [NSApplication run] processes and dispatches via sendEvent which
>> calls stop and makes [NSApplication run] return to its caller.
>
> Is there any way to initiate posting that "special application-defined
> event" when Emacs is stuck thusly?  For example, from some system
> signal-like event, or from a debugger?  Then you at least would have a
> fire escape.

Running under LLDB I can do something, with a little code change in
ns_send_appdefined.

  (lldb) expr ns_send_appdefined(-42)

where I let -42 force posting an event, ignoring the global variable I
mentioned, send_appdefined, that prevents the posting. Sometimes I have
to do that twice before Emacs receives key strokes again. And it seems
something is also broken afterwards, for example the cursor stops
blinking, tooltips don't work and such things. But at least one can save
buffers and exit.

I've tried this

  (when (fboundp 'ns-app-stop)
    (defun sigusr1-handler ()
      (interactive)
      (message "SIGUSR1 - stop event loop")
      (ns-app-stop))
    (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))

where ns-app-stop does such a ns_send_appdefined, but that didn't work
for a reason unknown to me. I also tried to do that in the signal
handler directly, but couldn't make it work either.

BTW, there are also freezes with beach ball, where the situation seems
to be reversed, i.e. for some reason [NSApplication run] seems to no
longer processing events, hence the beach ball. I haven't event a theory
what that could oossibly be caused by.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Tue, 06 Aug 2024 21:04:26 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 72496 <at> debbugs.gnu.org
> Date: Tue, 06 Aug 2024 18:36:39 +0200
> 
> I've tried this
> 
>   (when (fboundp 'ns-app-stop)
>     (defun sigusr1-handler ()
>       (interactive)
>       (message "SIGUSR1 - stop event loop")
>       (ns-app-stop))
>     (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))
> 
> where ns-app-stop does such a ns_send_appdefined, but that didn't work
> for a reason unknown to me.

Maybe the way SIGUSR1 is handled involves the same event queue that is
botched in this scenario?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Tue, 06 Aug 2024 20:37:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 72496 <at> debbugs.gnu.org
>> Date: Tue, 06 Aug 2024 18:36:39 +0200
>> 
>> I've tried this
>> 
>>   (when (fboundp 'ns-app-stop)
>>     (defun sigusr1-handler ()
>>       (interactive)
>>       (message "SIGUSR1 - stop event loop")
>>       (ns-app-stop))
>>     (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))
>> 
>> where ns-app-stop does such a ns_send_appdefined, but that didn't work
>> for a reason unknown to me.
>
> Maybe the way SIGUSR1 is handled involves the same event queue that is
> botched in this scenario?

Yes, that's quite likely. I had a little hope that a signal would maybe
handled in some special way, but apparently not.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Thu, 08 Aug 2024 07:24:57 +0200

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

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>> Cc: 72496 <at> debbugs.gnu.org
>>> Date: Tue, 06 Aug 2024 18:36:39 +0200
>>> 
>>> I've tried this
>>> 
>>>   (when (fboundp 'ns-app-stop)
>>>     (defun sigusr1-handler ()
>>>       (interactive)
>>>       (message "SIGUSR1 - stop event loop")
>>>       (ns-app-stop))
>>>     (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))
>>> 
>>> where ns-app-stop does such a ns_send_appdefined, but that didn't work
>>> for a reason unknown to me.
>>
>> Maybe the way SIGUSR1 is handled involves the same event queue that is
>> botched in this scenario?
>
> Yes, that's quite likely. I had a little hope that a signal would maybe
> handled in some special way, but apparently not.

I'm now running locally with the attached change. This removes the
global variable that can prevent sending app-defined events when set
wrong. Instead, I'm using [NSApplication nextEventMatchingMask] to check
if an app-defined event has already been posted. This is infinelty less
dangerous.

Let's see if that is the problem.

[0001-NS-Send-application-defined-event-differently-bug-72.patch (text/x-patch, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Sat, 10 Aug 2024 11:18:15 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>>> Cc: 72496 <at> debbugs.gnu.org
>>>> Date: Tue, 06 Aug 2024 18:36:39 +0200
>>>> 
>>>> I've tried this
>>>> 
>>>>   (when (fboundp 'ns-app-stop)
>>>>     (defun sigusr1-handler ()
>>>>       (interactive)
>>>>       (message "SIGUSR1 - stop event loop")
>>>>       (ns-app-stop))
>>>>     (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))
>>>> 
>>>> where ns-app-stop does such a ns_send_appdefined, but that didn't work
>>>> for a reason unknown to me.
>>>
>>> Maybe the way SIGUSR1 is handled involves the same event queue that is
>>> botched in this scenario?
>>
>> Yes, that's quite likely. I had a little hope that a signal would maybe
>> handled in some special way, but apparently not.
>
> I'm now running locally with the attached change. This removes the
> global variable that can prevent sending app-defined events when set
> wrong. Instead, I'm using [NSApplication nextEventMatchingMask] to check
> if an app-defined event has already been posted. This is infinelty less
> dangerous.
>
> Let's see if that is the problem.

I don't even know if this is related to my change to ns_send_appdefined, but
I got a freeze today while using child frames (vertico + posframe) that
I haven't seen before. Event the mouse behaved strangely on the whole
macOS until I killed the process. That was without beach ball.

So, whatever that was, my patch at least didn't help, if it wasn't
causing it.

I give up. I'll switch to using tty Emacs.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74369 <at> debbugs.gnu.org, adamkshannon <at> gmail.com, 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Wed, 28 May 2025 06:41:10 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

FWIW, and for posterity, I am now using the patch below. This makes the
freezes without beach ball that I described literally impossible. 

1 file changed, 17 insertions(+), 1 deletion(-)
src/nsterm.m | 18 +++++++++++++++++-

modified   src/nsterm.m
@@ -6132,7 +6132,23 @@ - (void)sendEvent: (NSEvent *)theEvent
 
   NSTRACE_UNSILENCE();
 
-  [super sendEvent: theEvent];
+  [super sendEvent:theEvent];
+
+#ifdef NS_IMPL_COCOA
+  /* We have the problem that app-defined events get lost for an unknown
+     reason. When that happens, Emacs still processes NS events, and no
+     beach ball is displayed. But Emacs' own event loop does not gain
+     control again and it doesn't react to input anymore.  */
+  if ([NSApp modalWindow] != nil)
+    return;
+
+  static int count = 0;
+  if (++count == 10)
+    {
+      count = 0;
+      [self stop: self];
+    }
+#endif
 }
 
 

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: adamkshannon <at> gmail.com, 74369 <at> debbugs.gnu.org, 72496 <at> debbugs.gnu.org
Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball
Date: Sun, 08 Jun 2025 06:43:31 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> FWIW, and for posterity, I am now using the patch below. This makes the
> freezes without beach ball that I described literally impossible. 

I take that back since I got another freeze with that patch.

Previous Next

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