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

Previous Next

Full log

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

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: Re: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Sat, 09 Mar 2024 10:47:43 +0100

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

>> Cc: 69561 <at> debbugs.gnu.org
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Thu, 07 Mar 2024 20:29:44 +0100
>>
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> >> Thanks. That's in if (read_kbd), and the first backtrace I sent had
>> >>
>> >>     frame #6: 0x00000001001d94d2
>> >> emacs`wait_reading_process_output(time_limit=<unavailable>,
>> >> nsecs=<unavailable>, read_kbd=0, do_display=false,
>> >> wait_for_cell=(struct Lisp_Symbol *) $123 = 0x00000001007d24b0,
>> >> wait_proc=0x00007fccffdcc9d8, just_wait_proc=0) at process.c:5484:9
>> >> [opt]
>> >>
>> >> i.e. read_kbd should be 0.
>> >>
>> >> Maybe that's also an explanation why it doesn't freeze most of time?
>> >> If it sometimes does detect_input_pending...
>> >
>> > So this
>> >
>> >    READ_KBD is:
>> >      0 to ignore keyboard input, or
>> >      1 to return when input is available, or
>> >     -1 meaning caller will actually read the input, so don't throw to
>> >        the quit handler
>> >
>> > implies that if read_kbd is zero then we should be able to quit?
>>
>> I'm afraid I can't answer that. Maybe Eli can, or knows someone who can?
>
> I think the fragment below answers the question?
>
>       /* If calling from keyboard input, do not quit
> 	 since we want to return C-g as an input character.
> 	 Otherwise, do pending quit if requested.  */
>       if (read_kbd >= 0)
> 	maybe_quit ();
>
> So yes, if read_kbd is zero, we should be able to quit.

Thanks!

>
>> > If that's the case then we need some special handling in nsterm.m for
>> > C-g, I suppose.
>> >
>> > Having dug around in other terms I assume this means setting
>> > Vquit_flag? So in the keyDown method we should identify C-g and set
>> > Vquit_flag...?
>>
>> As far as I understand the code, Vquit_flag will also be set by storing
>> the event in question with kbd_buffer_store_event_hold. I think that
>> would be the easiest way. And it's what ns_read_socket already does.
>
> Setting Vquit_flag directly has the advantage that it will cause C-g
> to be processed earlier, without waiting for all the previous queued
> inputs to be processed first.  In general, users expect C-g to be
> processed ASAP.

Ok, I now tried with this in keyDown, applied to current master, no
other changes. (keyDown is somewhat scary, if I may remark that ;-).

C-g is then recognized and Vquit_flag is set under normal circumstances,
which I can see on stderr.

diff --git a/src/nsterm.m b/src/nsterm.m
index f094b145fe3..a9539987411 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6875,10 +6878,17 @@ In that case we use UCKeyTranslate (ns_get_shifted_character)
                  of characters?  */
               emacs_event->kind = code > 0xFF
                 ? MULTIBYTE_CHAR_KEYSTROKE_EVENT : ASCII_KEYSTROKE_EVENT;
-            }
+	    }
+
+	  // This is probably wrong, it's just for testing.
+	  if (code == 'g' && (emacs_event->modifiers & ctrl_modifier))
+	    {
+	      fprintf (stderr, "C-g\n");
+	      Vquit_flag = Qt;
+	    }

           emacs_event->code = code;
-          EV_TRAILER (theEvent);
+	  EV_TRAILER (theEvent);
           processingCompose = NO;
           return;
         }


It didn't help in a freeze though. Apparently, keyDown isn't called
then, i.e. there's no output on stderr.

On second thought, I should probably have expected that, because the
system says that Emacs is unresponsive, which I think means it doesn't
process events.

So, that alone apparently doesn't help, although it appears it should be
done (in the right way, which I'm not sure I know.)

News from the last patch I sent for ns_select - I didn't have a freeze
with it so far, and I didn't observe any adverse effects either. So far
so good...

Any idea how to proceed with this, Eli and Alan?

Previous Next

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