Subject: Re: bug#72496: 31.0.50; macOS: freezes without beach ball

From: Gerd Möllmann <[email-masked]>
Date: Tue, 06 Aug 2024 18:36:39 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Gerd Möllmann <[email-masked]>
>> 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.