GNU bug report logs -
#72496
31.0.50; macOS: freezes without beach ball
Previous Next
Full log
Message #23 received at 72496 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 65 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.