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

Previous Next

Package: emacs;

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

Date: Tue, 5 Mar 2024 11:03:01 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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 13:11:58 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: alan <at> idiocy.org,  69561 <at> debbugs.gnu.org
> Date: Sat, 09 Mar 2024 12:00:36 +0100
> 
> > 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.

Are we talking about processing C-g or are we talking about processing
"normal" output from sub-processes?  I thought we were talking about
the latter?  If so, then C-g is not really relevant, and we need to
establish why stuff that comes from the sub-process is not processed
as we expect, by causing ns_select return something interesting.
Right?




This bug report was last modified 1 year and 125 days ago.

Previous Next


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