GNU bug report logs - #69561
30.0.50; Freeze from M-x gnus on macOS

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69561 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Sat, 09 Mar 2024 12:00:36 +0100

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

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

>> Any idea how to proceed with this, Eli and Alan?
>
> I'm afraid I've lost the relevant context.  Can you remind why Emacs
> is not responsive? does it infloop somewhere, and if so, where?

Yes, it loops in wait_reading_process_out, which calls ns_select without
making progress, and without handling NS events, which is the reason why
the system says Emacs is unresponsice (beach ball of death).

This can happen in various circumstances. I have seen freezes in epg
(decrypting autoinfo), flymake, json-rps (eglot + clangd) so far. And it
started to get really bad lately in master, for unknown reasons.

My analysis, all the usual disclaimers apply ;-)...

The NS port event handling works like so: NS has a queue named
hold_events_q of struct input_event (global variable). The queue is
filled when EmacsView receives NS events from the system. NS events are
processed by calling [NSApp run] with some ornamention around it to make
sure the call returns. ns_select and ns_read_socket do that.

The input_events in hold_events_q are given to Emacs in ns_read_socket,
which is installed for terminal type as read_socket_hook. That's how
normally a C-g is recognized by kdb_store_event and Vquit_flag is set.

But hold_events_q are _not_ kbd_store'd in ns_select. Instead we have

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

So, ns_select returns -1 to wait_reading_process_output which loops,
AFAICT.

By immediately returning -1 in ns_select it additionally also does not
run [NSApp run], which means NS/Cocoa events will not be processed. If
nobody else (ns_read_socket, for instance) is called in
from somehwere we're stuckin 2 ways:

- Existing input_events in hold_event_q are never transferred to the
  rest of Emacs.
- NS events are never processed, which leads to the beach ball.

So, I tried the attached patch to ns_select, which does 2 things:

- it makes sure that hold_event_q input_events are transferred to Emacs.
- it makes sure that [NSApp run] is always called.

Not that I really know what I'm doing, but it seems to work ;-)

[0001-ns_select.patch (text/x-patch, attachment)]

Previous Next

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