bug#69561: 30.0.50; Freeze from M-x gnus on macOS

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

I experienced another complete Emacs freeze today on macOS, this time
from M-x gnus.

This doesn't always happen, most of the time Gnus works just fine. It's
maybe also significant that I see freezes without using Gnus. I have not
found a recipe to reproduce the freezes at will.

Interrupting the process in LLDB shows

(lldb) xbacktrace
(unsigned char *) data = 0x00000001002a5cbd "accept-process-output"
(unsigned char *) data = 0x00007fccffcd8490 "epg-wait-for-status"
(unsigned char *) data = 0x00007fcd0129fb20 "epg-start-decrypt"
(unsigned char *) data = 0x00007fcd0129fc10 "epg-decrypt-file"
(unsigned char *) data = 0x00007fcd013b2a08 "epa-file-insert-file-contents"
(unsigned char *) data = 0x000000010029eb79 "apply"
(unsigned char *) data = 0x0000000175c52557 "epa-file-handler"
(unsigned char *) data = 0x000000010029b6e3 "insert-file-contents"
(unsigned char *) data = 0x00007fccff9dd398 "auth-source-netrc-parse"
(unsigned char *) data = 0x00007fccff9dcbe8 "auth-source-netrc-search"
(unsigned char *) data = 0x000000010029eb79 "apply"
(unsigned char *) data = 0x00007fccff9dd020 "auth-source-search-backends"
(unsigned char *) data = 0x00007fccff9dce48 "auth-source-search"
(unsigned char *) data = 0x00007fccffdf1138 "nntp-send-authinfo"
(unsigned char *) data = 0x00007fcd0180f9a8 "nntp-open-connection"
(unsigned char *) data = 0x00007fcd0180fc78 "nntp-open-server"
(unsigned char *) data = 0x00007fcd012ba800 "gnus-open-server"
(unsigned char *) data = 0x00007fcd012cd1c8 "gnus-start-news-server"
(unsigned char *) data = 0x00007fccffcca8c8 "gnus-1"
(unsigned char *) data = 0x0000000175c5d840 "gnus"
(unsigned char *) data = 0x000000010029e589 "funcall-interactively"
(unsigned char *) data = 0x000000010029e576 "call-interactively"
(unsigned char *) data = 0x00000001002a1a0f "command-execute"
(unsigned char *) data = 0x0000000175c74bc7 "execute-extended-command"
(unsigned char *) data = 0x000000010029e589 "funcall-interactively"
(unsigned char *) data = 0x000000010029e576 "call-interactively"
(unsigned char *) data = 0x00000001002a1a0f "command-execute"

It apparently doesn't come out of the accept-process-output, although
epg-wait-for-status specifies a timeout of 1 second.

On the C side, backtraces always show wait_reading_process_output on the
stack. This is AFAICT also the case in other freezes without using Gnus.


In GNU Emacs 30.0.50 (build 3, x86_64-apple-darwin23.3.0, NS
 appkit-2487.40 Version 14.3.1 (Build 23D60)) of 2024-03-05 built on
 Pro.fritz.box
Repository revision: 218748c26287ae865229fe8a3c520facfa12fede
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.3.1

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:
Forgot a sampel C backtrace

(lldb) bt 10
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff81b20f7f2 libsystem_kernel.dylib`__pthread_sigmask + 10
    frame #1: 0x00007ff81b2487f7 libsystem_pthread.dylib`pthread_sigmask + 9
    frame #2: 0x000000010010bc60 emacs`block_interrupt_signal(oldset=<unavailable>) at sysdep.c:891:3 [opt]
    frame #3: 0x00000001002024d0 emacs`really_call_select(arg=0x00007ff7bfef9008) at thread.c:619:3 [opt]
    frame #4: 0x0000000100202490 emacs`thread_select [inlined] flush_stack_call_func(func=<unavailable>, arg=0x00007ff7bfef9008) at lisp.h:4457:3 [opt]
    frame #5: 0x0000000100202480 emacs`thread_select(func=<unavailable>, max_fds=<unavailable>, rfds=<unavailable>, wfds=<unavailable>, efds=<unavailable>, timeout=<unavailable>, sigmask=0x0000000000000000) at thread.c:656:3 [opt]
    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]
    frame #7: 0x00000001001d8bdc emacs`Faccept_process_output(process=<unavailable>, seconds=(EMACS_INT) $132 = 1, millisec=<unavailable>, just_this_one=(struct Lisp_Symbol *) $150 = 0x00000001007d24b0) at process.c:4912:7 [opt]
    frame #8: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #9: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Happened again, this time when sending a mail to Alan in debbugs-gnu.

Stepping through wait_reading_process_output one can see that ns_select
is called again and again and again without progress. (Alas, I don't
understand this function anymore, so I can't extract hints out of
what I'm seeing.)

I'm now trying with older versions of master, because HEAD seems to be
currently unusable.

(lldb) xbacktrace
(unsigned char *) data = 0x00000001002a5cbd "accept-process-output"
(unsigned char *) data = 0x00007f87f15597f8 "epg-wait-for-status"
(unsigned char *) data = 0x00007f87f155ac80 "epg-start-decrypt"
(unsigned char *) data = 0x00007f87f155ad70 "epg-decrypt-file"
(unsigned char *) data = 0x00007f87f68b7798 "epa-file-insert-file-contents"
(unsigned char *) data = 0x000000010029eb79 "apply"
(unsigned char *) data = 0x0000000175c52557 "epa-file-handler"
(unsigned char *) data = 0x000000010029b6e3 "insert-file-contents"
(unsigned char *) data = 0x00007f87f2042ea0 "auth-source-netrc-parse"
(unsigned char *) data = 0x00007f87f20426f0 "auth-source-netrc-search"
(unsigned char *) data = 0x000000010029eb79 "apply"
(unsigned char *) data = 0x00007f87f2042b28 "auth-source-search-backends"
(unsigned char *) data = 0x00007f87f2042950 "auth-source-search"
(unsigned char *) data = 0x00007f87f15f3f80 "network-stream-certificate"
(unsigned char *) data = 0x00007f87efb6e6a8 "network-stream-open-starttls"
(unsigned char *) data = 0x00000001002a33bd "open-network-stream"
(unsigned char *) data = 0x00007f87efbbc638 "smtpmail-via-smtp"
(unsigned char *) data = 0x0000000175cf968b "smtpmail-send-it"
(unsigned char *) data = 0x00007f87f157c688 "message-use-send-mail-function"
(unsigned char *) data = 0x00007f87f157c6b0 "message--default-send-mail-function"
(unsigned char *) data = 0x00007f87f158bea0 "message-multi-smtp-send-mail"
(unsigned char *) data = 0x00007f87f158bf90 "message--send-mail-maybe-partially"
(unsigned char *) data = 0x00007f87f158b5f8 "message-send-mail"
(unsigned char *) data = 0x00007f87f157def8 "message-send-via-mail"
(unsigned char *) data = 0x00007f87f1585680 "message-send"
(unsigned char *) data = 0x0000000175c5d433 "message-send-and-exit"
(unsigned char *) data = 0x000000010029e589 "funcall-interactively"
(unsigned char *) data = 0x000000010029e576 "call-interactively"
(unsigned char *) data = 0x00000001002a1a0f "command-execute"

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff81b20f7f2 libsystem_kernel.dylib`__pthread_sigmask + 10
    frame #1: 0x00007ff81b2487f7 libsystem_pthread.dylib`pthread_sigmask + 9
    frame #2: 0x0000000100202545 emacs`really_call_select(arg=0x00007ff7bfef9288) at thread.c:639:3 [opt]
    frame #3: 0x0000000100202490 emacs`thread_select [inlined] flush_stack_call_func(func=<unavailable>, arg=0x00007ff7bfef9288) at lisp.h:4457:3 [opt]
    frame #4: 0x0000000100202480 emacs`thread_select(func=<unavailable>, max_fds=38, rfds=<unavailable>, wfds=<unavailable>, efds=<unavailable>, timeout=<unavailable>, sigmask=0x0000000000000000) at thread.c:656:3 [opt]
    frame #5: 0x0000000100226a74 emacs`ns_select_1(nfds=38, readfds=0x00007ff7bfef9580, writefds=0x00007ff7bfef9460, exceptfds=0x0000000000000000, timeout=0x00007ff7bfef9670, sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4760:12 [opt]
    frame #6: 0x0000000100226704 emacs`ns_select(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at nsterm.m:4888:10 [opt]
    frame #7: 0x00000001001d9e3d emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=0, do_display=false, wait_for_cell=(struct Lisp_Symbol *) $423 = 0x00000001007d24b0, wait_proc=0x00007f87f20f8218, just_wait_proc=0) at process.c:5748:18 [opt]
    frame #8: 0x00000001001d8bdc emacs`Faccept_process_output(process=<unavailable>, seconds=(EMACS_INT) $432 = 1, millisec=<unavailable>, just_this_one=(struct Lisp_Symbol *) $450 = 0x00000001007d24b0) at process.c:4912:7 [opt]
    frame #9: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #10: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #11: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #12: 0x000000010017e14a emacs`Ffuncall(nargs=6, args=(struct Lisp_Symbol *) $463 = 0x00007ff8c06cbde0) at eval.c:3022:21 [opt]
    frame #13: 0x00000001001825ad emacs`Fapply(nargs=2, args=<unavailable>) at eval.c:2693:24 [opt]
    frame #14: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #15: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #16: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #17: 0x000000010017e14a emacs`Ffuncall(nargs=7, args=(struct Lisp_Symbol *) $474 = 0x00007ff8c06cc330) at eval.c:3022:21 [opt]
    frame #18: 0x000000010012ccf2 emacs`Finsert_file_contents(filename=(struct Lisp_String *) $481 = 0x00007f87f8507750, visit=(struct Lisp_Symbol *) $499 = 0x00000001007d24b0, beg=(struct Lisp_Symbol *) $520 = 0x00000001007d24b0, end=(struct Lisp_Symbol *) $541 = 0x00000001007d24b0, replace=(struct Lisp_Symbol *) $562 = 0x00000001007d24b0) at fileio.c:4132:13 [opt]
    frame #19: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #20: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #21: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #22: 0x000000010017e14a emacs`Ffuncall(nargs=19, args=(struct Lisp_Symbol *) $575 = 0x00007ff8c06d0810) at eval.c:3022:21 [opt]
    frame #23: 0x00000001001825ad emacs`Fapply(nargs=14, args=<unavailable>) at eval.c:2693:24 [opt]
    frame #24: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #25: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #26: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #27: 0x00000001001ce400 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:816:14 [opt]
    frame #28: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #29: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #30: 0x000000010017e14a emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $586 = 0x00007ff8c06d0d58) at eval.c:3022:21 [opt]
    frame #31: 0x000000010017a777 emacs`Ffuncall_interactively(nargs=2, args=(struct Lisp_Symbol *) $597 = 0x00007ff8c06d0d58) at callint.c:250:32 [opt]
    frame #32: 0x000000010017e14a emacs`Ffuncall(nargs=3, args=(struct Lisp_Symbol *) $608 = 0x00007ff8c06d0d50) at eval.c:3022:21 [opt]
    frame #33: 0x000000010017bcd8 emacs`Fcall_interactively(function=(struct Lisp_Symbol *) $627 = 0x0000000175229860, record_flag=(struct Lisp_Symbol *) $648 = 0x00000001007d24b0, keys=(struct Lisp_Vector *) $657 = 0x00007f87f1164298) at callint.c:789:21 [opt]
    frame #34: 0x00000001001ce53c emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:814:14 [opt]
    frame #35: 0x0000000100183d60 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3194:9 [opt] [artificial]
    frame #36: 0x0000000100183583 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] [artificial]
    frame #37: 0x000000010017e14a emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $667 = 0x00007ff8c06d1210) at eval.c:3022:21 [opt]
    frame #38: 0x00000001000eba62 emacs`command_loop_1 at keyboard.c:1549:13 [opt]
    frame #39: 0x0000000100180956 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1323), handlers=(struct Lisp_Symbol *) $686 = 0x00000001007d2540, hfun=(emacs`cmd_error at keyboard.c:969)) at eval.c:1537:25 [opt]
    frame #40: 0x00000001000eb43e emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $707 = 0x00000001007d2540) at keyboard.c:1167:11 [opt]
    frame #41: 0x000000010017ff80 emacs`internal_catch(tag=(struct Lisp_Symbol *) $728 = 0x00000001007e2020, func=(emacs`command_loop_2 at keyboard.c:1163), arg=(struct Lisp_Symbol *) $749 = 0x00000001007d2540) at eval.c:1217:25 [opt]
    frame #42: 0x00000001000eac44 emacs`command_loop at keyboard.c:1145:2 [opt]
    frame #43: 0x00000001000eaabb emacs`recursive_edit_1 at keyboard.c:753:9 [opt]
    frame #44: 0x00000001000eae38 emacs`Frecursive_edit at keyboard.c:836:3 [opt]
    frame #45: 0x00000001000e9991 emacs`main(argc=<unavailable>, argv=0x00007ff7bfeff3a0) at emacs.c:2624:3 [opt]
    frame #46: 0x00007ff81aebe386 dyld`start + 1942
  thread #2, name = 'gmain'
    frame #0: 0x00007ff81b21291e libsystem_kernel.dylib`__select + 10
    frame #1: 0x00000001012cc632 libglib-2.0.0.dylib`g_poll + 505
    frame #2: 0x00000001012bde80 libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 299
    frame #3: 0x00000001012bdf31 libglib-2.0.0.dylib`g_main_context_iteration + 55
    frame #4: 0x00000001012bef22 libglib-2.0.0.dylib`glib_worker_main + 30
    frame #5: 0x00000001012e3739 libglib-2.0.0.dylib`g_thread_proxy + 66
    frame #6: 0x00007ff81b249202 libsystem_pthread.dylib`_pthread_start + 99
    frame #7: 0x00007ff81b244bab libsystem_pthread.dylib`thread_start + 15
  thread #5
    frame #0: 0x00007ff81b20e83a libsystem_kernel.dylib`__pselect + 10
    frame #1: 0x00007ff81b20e72f libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
    frame #2: 0x00000001002291b2 emacs`-[EmacsApp fd_handler:](self=<unavailable>, _cmd=<unavailable>, unused=<unavailable>) at nsterm.m:6323:20 [opt]
    frame #3: 0x00007ff81c2b771c Foundation`__NSThread__start__ + 1013
    frame #4: 0x00007ff81b249202 libsystem_pthread.dylib`_pthread_start + 99
    frame #5: 0x00007ff81b244bab libsystem_pthread.dylib`thread_start + 15
  thread #7, name = 'com.apple.NSEventThread'
    frame #0: 0x00007ff81b209a2e libsystem_kernel.dylib`mach_msg2_trap + 10
    frame #1: 0x00007ff81b217e3a libsystem_kernel.dylib`mach_msg2_internal + 84
    frame #2: 0x00007ff81b210b62 libsystem_kernel.dylib`mach_msg_overwrite + 653
    frame #3: 0x00007ff81b209d1f libsystem_kernel.dylib`mach_msg + 19
    frame #4: 0x00007ff81b325135 CoreFoundation`__CFRunLoopServiceMachPort + 143
    frame #5: 0x00007ff81b323ba5 CoreFoundation`__CFRunLoopRun + 1371
    frame #6: 0x00007ff81b323082 CoreFoundation`CFRunLoopRunSpecific + 557
    frame #7: 0x00007ff81ea90aac AppKit`_NSEventThread + 122
    frame #8: 0x00007ff81b249202 libsystem_pthread.dylib`_pthread_start + 99
    frame #9: 0x00007ff81b244bab libsystem_pthread.dylib`thread_start + 15
  thread #28
    frame #0: 0x00007ff81b20b152 libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff81b245ca0 libsystem_pthread.dylib`_pthread_wqthread + 416
    frame #2: 0x00007ff81b244b97 libsystem_pthread.dylib`start_wqthread + 15
  thread #29
    frame #0: 0x00007ff81b244b88 libsystem_pthread.dylib`start_wqthread

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Tue, 05 Mar 2024 15:29:51 +0100
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> Happened again, this time when sending a mail to Alan in debbugs-gnu.
> 
> Stepping through wait_reading_process_output one can see that ns_select
> is called again and again and again without progress.

That probably means the descriptor on which ns_select was supposed to
wait doesn't become read-ready for some reason.  Can you figure out
which descriptor is that, and then what happened to the process from
which we want to read via that descriptor?  Maybe the descriptor mask
used in ns_select call is wrong, and the bit corresponding to the
subprocess' descriptor is not set for some reason?

But wait: epg-wait-for-status seems to wait for one or more processes
to exit.  So what is the status of the process for which it waits?  Is
it running, or did it perhaps already exit?

And one other thing: what is the version of GnuPG you are using here?
There's an entry in PROBLEMS about hangs related to some versions of
GnuPG; could that be your problem here?

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Tue, 05 Mar 2024 15:29:51 +0100
>> 
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> 
>> Happened again, this time when sending a mail to Alan in debbugs-gnu.
>> 
>> Stepping through wait_reading_process_output one can see that ns_select
>> is called again and again and again without progress.
>
> That probably means the descriptor on which ns_select was supposed to
> wait doesn't become read-ready for some reason.  Can you figure out
> which descriptor is that, and then what happened to the process from
> which we want to read via that descriptor?  Maybe the descriptor mask
> used in ns_select call is wrong, and the bit corresponding to the
> subprocess' descriptor is not set for some reason?

Thanks for taking a look at this with me.

I didn't take a closer look at ns_select etc. in LLDB, sorry. It was a
build with -O2, ... ;-)

> But wait: epg-wait-for-status seems to wait for one or more processes
> to exit.  So what is the status of the process for which it waits?  Is
> it running, or did it perhaps already exit?

I could see gpg running in Activity Monitor.

> And one other thing: what is the version of GnuPG you are using here?
> There's an entry in PROBLEMS about hangs related to some versions of
> GnuPG; could that be your problem here?

PROBLEMS says I have the version with the fix for the hang:

  .../github/igc/src % gpg --version
  gpg (GnuPG) 2.4.4
  libgcrypt 1.10.3
          
The situation is like this, as I see it here:

- Emacs master worked fine a while ago. Alas, I can't say when this
  started because I usually don't use master, but a local version, that
  is dervied from master, but that I don't merge with master frequently.

- I think most freezes I've seen during the last days were with Eglot
  using clangd. They looked very similar to the ones with Gnus, with a
  different Lisp backtrace of course. So, it's probably not gpg.

I'm currently trying to bisect when this problem started. I can't force
the freeze to happen, but I hope that surviving a day or two can be
counted as a good version, when it freezes at leasst once a day with
master. Maybe I can find the culprit that way.

So far, a3d7092114db09fee392ccc8187fde03376f2089 seems to behave well,
which is from CommitDate: Sun Jan 28 00:26:44 2024 -0800

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 69561@debbugs.gnu.org
> Date: Tue, 05 Mar 2024 17:38:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But wait: epg-wait-for-status seems to wait for one or more processes
> > to exit.  So what is the status of the process for which it waits?  Is
> > it running, or did it perhaps already exit?
> 
> I could see gpg running in Activity Monitor.

"Running" as in "consuming CPU", or just didn't exit yet?

Maybe you should attach a debugger to gpg and try to understand what
is it doing and why it doesn't exit?

> I'm currently trying to bisect when this problem started. I can't force
> the freeze to happen, but I hope that surviving a day or two can be
> counted as a good version, when it freezes at leasst once a day with
> master. Maybe I can find the culprit that way.

Could be.  But if you could establish why gpg isn't exiting, you could
perhaps make progress faster.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: 69561@debbugs.gnu.org
>> Date: Tue, 05 Mar 2024 17:38:14 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > But wait: epg-wait-for-status seems to wait for one or more processes
>> > to exit.  So what is the status of the process for which it waits?  Is
>> > it running, or did it perhaps already exit?
>> 
>> I could see gpg running in Activity Monitor.
>
> "Running" as in "consuming CPU", or just didn't exit yet?

Sorry, I don't know. I just saw gpg in the list.

> Maybe you should attach a debugger to gpg and try to understand what
> is it doing and why it doesn't exit?
>
>> I'm currently trying to bisect when this problem started. I can't force
>> the freeze to happen, but I hope that surviving a day or two can be
>> counted as a good version, when it freezes at leasst once a day with
>> master. Maybe I can find the culprit that way.
>
> Could be.  But if you could establish why gpg isn't exiting, you could
> perhaps make progress faster.

Maybe, but the bisecting has at least the davantage that I can do what I
really wanted to, and just wait for Emacs to eventually freeze or not.
And the builds in between can also run unattended. TRT for a lazy old
lad ;-).

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

(CC'd to Alan.)

As a reminder, the freezes are especially annoying because one cannot
C-g out of them. I read the NS code today, and I think I at least have a
strong suspicion why that is.

Let's just simplify things and say that the NS code 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, for example
C-g. NS events are processed by calling [NSApp run] with some
ornamention around it to make sure the calls 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_out which loops,
AFAICT.

      if (nfds < 0)
	{
	  if (xerrno == EINTR)
	    no_avail = 1;
...
      if (no_avail || nfds == 0)
	continue;

And Vquit_flag is never changing because the C-g is still in
hold_events_q, and maybe_quit does nothing.

Does that make sense? 

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> (CC'd to Alan.)
>
> As a reminder, the freezes are especially annoying because one cannot
> C-g out of them. I read the NS code today, and I think I at least have a
> strong suspicion why that is.
>
> Let's just simplify things and say that the NS code 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, for example
> C-g. NS events are processed by calling [NSApp run] with some
> ornamention around it to make sure the calls 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_out which loops,
> AFAICT.
>
>       if (nfds < 0)
> 	{
> 	  if (xerrno == EINTR)
> 	    no_avail = 1;
> ...
>       if (no_avail || nfds == 0)
> 	continue;
>
> And Vquit_flag is never changing because the C-g is still in
> hold_events_q, and maybe_quit does nothing.
>
> Does that make sense? 

I'm now using the below change. This should also lead to NS events being
processed.

1 file changed, 6 insertions(+), 5 deletions(-)
src/nsterm.m | 11 ++++++-----

modified   src/nsterm.m
@@ -4739,12 +4739,13 @@ Function modeled after x_draw_glyph_string_box ().
   check_native_fs ();
 #endif
 
-  if (hold_event_q.nr > 0 && !run_loop_only)
+  /* If there are input events pending, store them so that
+     Emacs can recognize C-g.  */
+  if (hold_event_q.nr > 0)
     {
-      /* We already have events pending.  */
-      raise (SIGIO);
-      errno = EINTR;
-      return -1;
+      for (int i = 0; i < hold_event_q.nr; ++i)
+        kbd_buffer_store_event_hold (&hold_event_q.q[i], NULL);
+      hold_event_q.nr = 0;
     }
 
   eassert (nfds <= FD_SETSIZE);

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Alan Third]

On Thu, Mar 07, 2024 at 04:18:00PM +0100, Gerd Möllmann wrote:
> (CC'd to Alan.)
> 
> As a reminder, the freezes are especially annoying because one cannot
> C-g out of them. I read the NS code today, and I think I at least have a
> strong suspicion why that is.
> 
> Let's just simplify things and say that the NS code 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, for example
> C-g. NS events are processed by calling [NSApp run] with some
> ornamention around it to make sure the calls 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_out which loops,
> AFAICT.
> 
>       if (nfds < 0)
> 	{
> 	  if (xerrno == EINTR)
> 	    no_avail = 1;
> ...
>       if (no_avail || nfds == 0)
> 	continue;
> 
> And Vquit_flag is never changing because the C-g is still in
> hold_events_q, and maybe_quit does nothing.
> 
> Does that make sense? 

But keyboard input (ns_read_socket) is handled immediately after that
"if (nfds < 0)" block and well before the "if (no_avail...".

That would imply to me that keyboard input, and therefore the C-g, is
being blocked for some reason. Perhaps block_input() has been called?

I'm no expert on how this part of Emacs works so I'm probably
completely misunderstanding this.
-- 
Alan Third

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Alan Third <alan@idiocy.org> writes:

> On Thu, Mar 07, 2024 at 04:18:00PM +0100, Gerd Möllmann wrote:
>> (CC'd to Alan.)
>> 
>> As a reminder, the freezes are especially annoying because one cannot
>> C-g out of them. I read the NS code today, and I think I at least have a
>> strong suspicion why that is.
>> 
>> Let's just simplify things and say that the NS code 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, for example
>> C-g. NS events are processed by calling [NSApp run] with some
>> ornamention around it to make sure the calls 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_out which loops,
>> AFAICT.
>> 
>>       if (nfds < 0)
>> 	{
>> 	  if (xerrno == EINTR)
>> 	    no_avail = 1;
>> ...
>>       if (no_avail || nfds == 0)
>> 	continue;
>> 
>> And Vquit_flag is never changing because the C-g is still in
>> hold_events_q, and maybe_quit does nothing.
>> 
>> Does that make sense? 
>
> But keyboard input (ns_read_socket) is handled immediately after that
> "if (nfds < 0)" block and well before the "if (no_avail...".

Could you please tell the line number?

> That would imply to me that keyboard input, and therefore the C-g, is
> being blocked for some reason. Perhaps block_input() has been called?
>
> I'm no expert on how this part of Emacs works so I'm probably
> completely misunderstanding this.

Me neither, so many things have changed in only 20 years... :-)

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Alan Third]

On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > But keyboard input (ns_read_socket) is handled immediately after that
> > "if (nfds < 0)" block and well before the "if (no_avail...".
> 
> Could you please tell the line number?

detect_input_pending_run_timers at process.c:5839 calls
get_input_pending which calls gobble_input which calls
t->read_socket_hook.

There seem to be a lot of ways for it to bail out, though.

-- 
Alan Third

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Alan Third <alan@idiocy.org> writes:

> On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> > But keyboard input (ns_read_socket) is handled immediately after that
>> > "if (nfds < 0)" block and well before the "if (no_avail...".
>> 
>> Could you please tell the line number?
>
> detect_input_pending_run_timers at process.c:5839 calls
> get_input_pending which calls gobble_input which calls
> t->read_socket_hook.
>
> There seem to be a lot of ways for it to bail out, though.

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...

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Alan Third]

On Thu, Mar 07, 2024 at 06:01:02PM +0100, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
> >> Alan Third <alan@idiocy.org> writes:
> >> 
> >> > But keyboard input (ns_read_socket) is handled immediately after that
> >> > "if (nfds < 0)" block and well before the "if (no_avail...".
> >> 
> >> Could you please tell the line number?
> >
> > detect_input_pending_run_timers at process.c:5839 calls
> > get_input_pending which calls gobble_input which calls
> > t->read_socket_hook.
> >
> > There seem to be a lot of ways for it to bail out, though.
> 
> 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?

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...?

-- 
Alan Third

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Alan Third <alan@idiocy.org> writes:

> On Thu, Mar 07, 2024 at 06:01:02PM +0100, Gerd Möllmann wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> > On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
>> >> Alan Third <alan@idiocy.org> writes:
>> >> 
>> >> > But keyboard input (ns_read_socket) is handled immediately after that
>> >> > "if (nfds < 0)" block and well before the "if (no_avail...".
>> >> 
>> >> Could you please tell the line number?
>> >
>> > detect_input_pending_run_timers at process.c:5839 calls
>> > get_input_pending which calls gobble_input which calls
>> > t->read_socket_hook.
>> >
>> > There seem to be a lot of ways for it to bail out, though.
>> 
>> 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?

> 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.

In addition, returning -1 from ns_select if events are in the hold
queue, and not doing anything else, looks super suspicious to me. If
no-one else does an [NSApp run], like in my freeze, I think it's natural
that the system says Emacs is not responding. And what dowensides would
it have to [NSApp run]?

And finally, I would at least question the raise (SIGIO). I don't
understand the reason for that if, for example, keyboard input is the
hold queue. And, of course there is no comment...

But that just my 2 cents as a newcomer :-). 

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

On 07.03.24 20:29, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
> 
>> On Thu, Mar 07, 2024 at 06:01:02PM +0100, Gerd Möllmann wrote:
>>> Alan Third <alan@idiocy.org> writes:
>>>
>>>> On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
>>>>> Alan Third <alan@idiocy.org> writes:
>>>>>
>>>>>> But keyboard input (ns_read_socket) is handled immediately after that
>>>>>> "if (nfds < 0)" block and well before the "if (no_avail...".
>>>>>
>>>>> Could you please tell the line number?
>>>>
>>>> detect_input_pending_run_timers at process.c:5839 calls
>>>> get_input_pending which calls gobble_input which calls
>>>> t->read_socket_hook.
>>>>
>>>> There seem to be a lot of ways for it to bail out, though.
>>>
>>> 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?
> 
>> 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.
> 
> In addition, returning -1 from ns_select if events are in the hold
> queue, and not doing anything else, looks super suspicious to me. If
> no-one else does an [NSApp run], like in my freeze, I think it's natural
> that the system says Emacs is not responding. And what dowensides would
> it have to [NSApp run]?
> 
> And finally, I would at least question the raise (SIGIO). I don't
> understand the reason for that if, for example, keyboard input is the
> hold queue. And, of course there is no comment...
> 
> But that just my 2 cents as a newcomer :-).

And I had another freeze a few minutes ago, while starting Emacs, and 
from Eglot starting and doing json_rpc. Backtrace as usual, and it 
happened with the patch I sent before and without.

This time the problem was from something else in ns_select: the "return 
thread_select..." without doing [NSApp run].

With the change below Emacs started without problems. I guess something 
is seriously wrong in ns_select and/or wait_reading_process_output...

1 file changed, 7 insertions(+), 6 deletions(-)
src/nsterm.m | 13 +++++++------

modified   src/nsterm.m
@@ -4739,12 +4739,13 @@ Function modeled after x_draw_glyph_string_box ().
    check_native_fs ();
  #endif

-  if (hold_event_q.nr > 0 && !run_loop_only)
+  /* If there are input events pending, store them so that
+     Emacs can recognize C-g.  */
+  if (hold_event_q.nr > 0)
      {
-      /* We already have events pending.  */
-      raise (SIGIO);
-      errno = EINTR;
-      return -1;
+      for (int i = 0; i < hold_event_q.nr; ++i)
+        kbd_buffer_store_event_hold (&hold_event_q.q[i], NULL);
+      hold_event_q.nr = 0;
      }

    eassert (nfds <= FD_SETSIZE);
@@ -4757,7 +4758,7 @@ Function modeled after x_draw_glyph_string_box ().
    if (NSApp == nil
        || ![NSThread isMainThread]
        || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
-    return thread_select (pselect, nfds, readfds, writefds,
+    thread_select (pselect, nfds, readfds, writefds,
  			  exceptfds, timeout, sigmask);
    else
      {

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> And I had another freeze a few minutes ago, while starting Emacs, and
> from Eglot starting and doing json_rpc. Backtrace as usual, and it
> happened with the patch I sent before and without.

Just wanted to add another observation: how reliably freezes happen
apparently also depends on how I build Emacs. In a slow Emacs (debug
build on x86), Emacs freezes less frequently than in a fast build
(debug build on M1, or build with -O2 on x86).

This let's me suspect a timing issue.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> Cc: 69561@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 07 Mar 2024 20:29:44 +0100
> 
> Alan Third <alan@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.

> > 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.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 69561@debbugs.gnu.org
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Thu, 07 Mar 2024 20:29:44 +0100
>>
>> Alan Third <alan@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?

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> Date: Sat, 09 Mar 2024 10:47:43 +0100
> 
> 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?

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?

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

Eli Zaretskii <eliz@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 ;-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ns_select patch --]
[-- Type: text/x-patch, Size: 1057 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index f094b145fe3..075d1af0938 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4739,12 +4739,13 @@ Function modeled after x_draw_glyph_string_box ().
   check_native_fs ();
 #endif
 
-  if (hold_event_q.nr > 0 && !run_loop_only)
+  /* If there are input events pending, store them so that
+     Emacs can recognize C-g.  */
+  if (hold_event_q.nr > 0)
     {
-      /* We already have events pending.  */
-      raise (SIGIO);
-      errno = EINTR;
-      return -1;
+      for (int i = 0; i < hold_event_q.nr; ++i)
+        kbd_buffer_store_event_hold (&hold_event_q.q[i], NULL);
+      hold_event_q.nr = 0;
     }
 
   eassert (nfds <= FD_SETSIZE);
@@ -4757,7 +4758,7 @@ Function modeled after x_draw_glyph_string_box ().
   if (NSApp == nil
       || ![NSThread isMainThread]
       || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
-    return thread_select (pselect, nfds, readfds, writefds,
+    thread_select (pselect, nfds, readfds, writefds,
 			  exceptfds, timeout, sigmask);
   else
     {

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@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?

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: alan@idiocy.org,  69561@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?

Right, sorry, C-g came only into play because I tbought the current
sitution might become bearable if it could at least be interrupted with
C-g. And then I understoof the drama better.

If you take a look at the first hunk of the patch I sent, you can see
that ns_select can do _nothing_ interesting at all, it just returns -1.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> Date: Sat, 09 Mar 2024 12:33:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: alan@idiocy.org,  69561@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?
> 
> Right, sorry, C-g came only into play because I tbought the current
> sitution might become bearable if it could at least be interrupted with
> C-g. And then I understoof the drama better.
> 
> If you take a look at the first hunk of the patch I sent, you can see
> that ns_select can do _nothing_ interesting at all, it just returns -1.

But your patch still doesn't solve the problem, does it?

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right, sorry, C-g came only into play because I tbought the current
>> sitution might become bearable if it could at least be interrupted with
>> C-g. And then I understoof the drama better.
>> 
>> If you take a look at the first hunk of the patch I sent, you can see
>> that ns_select can do _nothing_ interesting at all, it just returns -1.
>
> But your patch still doesn't solve the problem, does it?

I'd say it does:

- it ensures that a "real" select is called, which formerly wasn't
  guaranteed
  
- it makes sure that queued input_events are passed to Emacs, for C-g
  detection, Vquit_flag and so on.
  
- it makes sure NS events are processed, so that C-g has a chance to get
  into the queued input_events in the first place, from processing
  keyDown events.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> Date: Sat, 09 Mar 2024 14:21:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Right, sorry, C-g came only into play because I tbought the current
> >> sitution might become bearable if it could at least be interrupted with
> >> C-g. And then I understoof the drama better.
> >> 
> >> If you take a look at the first hunk of the patch I sent, you can see
> >> that ns_select can do _nothing_ interesting at all, it just returns -1.
> >
> > But your patch still doesn't solve the problem, does it?
> 
> I'd say it does:
> 
> - it ensures that a "real" select is called, which formerly wasn't
>   guaranteed
>   
> - it makes sure that queued input_events are passed to Emacs, for C-g
>   detection, Vquit_flag and so on.
>   
> - it makes sure NS events are processed, so that C-g has a chance to get
>   into the queued input_events in the first place, from processing
>   keyDown events.

In that case, I think you should proceed by collecting experience with
this patch.  If the freezes indeed go away, then I think you should
install it.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> In that case, I think you should proceed by collecting experience with
> this patch.  If the freezes indeed go away, then I think you should
> install it.

Ok, thanks.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Pushed to mater and closing.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Filipp Gunbin]

On 13/03/2024 07:11 +0100, Gerd Möllmann wrote:

> Pushed to mater and closing.

(I haven't read this thread in detail) On TTY there were no freezes
before the patch, but now there are - for example, `C-x v L' in emacs
repo freezes.

Thanks.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 13/03/2024 07:11 +0100, Gerd Möllmann wrote:
>
>> Pushed to mater and closing.
>
> (I haven't read this thread in detail) On TTY there were no freezes
> before the patch, but now there are - for example, `C-x v L' in emacs
> repo freezes.

Thanks, Filipp. Could you please try the attached patch?

But - are you sure you see a freeze, i.e. you can't, don't know, C-x C-c
or C-g or whatever else? That's not what I see with emacs -nw -Q, I see
an empty log window.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 13/03/2024 07:11 +0100, Gerd Möllmann wrote:
>
>> Pushed to mater and closing.
>
> (I haven't read this thread in detail) On TTY there were no freezes
> before the patch, but now there are - for example, `C-x v L' in emacs
> repo freezes.
>
> Thanks.

Thanks, Filipp. Could you please try the attached patch?

But - are you sure you see a freeze, i.e. you can't, don't know, C-x C-c
or C-g or whatever else? That's not what I see with emacs -nw -Q, I see
an empty log window.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ns_select --]
[-- Type: text/x-patch, Size: 698 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index f161edc4ac2..97d6329cf4b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4757,9 +4757,11 @@ Function modeled after x_draw_glyph_string_box ().
       if (writefds && FD_ISSET(k, writefds)) ++nr;
     }
 
-  if (NSApp == nil
-      || ![NSThread isMainThread]
-      || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
+  if (NSApp == nil)
+    return thread_select (pselect, nfds, readfds, writefds,
+			  exceptfds, timeout, sigmask);
+  else if (![NSThread isMainThread]
+	   || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
     thread_select (pselect, nfds, readfds, writefds,
 		   exceptfds, timeout, sigmask);
   else

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Filipp Gunbin]

On 13/03/2024 19:20 +0100, Gerd Möllmann wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 13/03/2024 07:11 +0100, Gerd Möllmann wrote:
>>
>>> Pushed to mater and closing.
>>
>> (I haven't read this thread in detail) On TTY there were no freezes
>> before the patch, but now there are - for example, `C-x v L' in emacs
>> repo freezes.
>>
>> Thanks.
>
> Thanks, Filipp. Could you please try the attached patch?

Hi Gerd, yes it fixes the issue, thanks!

> But - are you sure you see a freeze, i.e. you can't, don't know, C-x C-c
> or C-g or whatever else? That's not what I see with emacs -nw -Q, I see
> an empty log window.

Yes, you're right, technically Emacs does not freeze here, but it does
nothing about the started git process (which can be seen in M-x
list-processes), the same even with "M-& echo foo RET" - just blank
screen.  With M-x gnus I was able to C-g, but otherwise it just hanged -
that's what I interpreted as related to this thread/commit.  Anyway it
seems ok with your fix now.

bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Gerd Möllmann]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 13/03/2024 19:20 +0100, Gerd Möllmann wrote:
>
>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>
>>> On 13/03/2024 07:11 +0100, Gerd Möllmann wrote:
>>>
>>>> Pushed to mater and closing.
>>>
>>> (I haven't read this thread in detail) On TTY there were no freezes
>>> before the patch, but now there are - for example, `C-x v L' in emacs
>>> repo freezes.
>>>
>>> Thanks.
>>
>> Thanks, Filipp. Could you please try the attached patch?
>
> Hi Gerd, yes it fixes the issue, thanks!

Thanks Filipp, glad to hear. I've pushed that to master, with a comment
added. I always forget Emacs on terminals because I never use that,
sorry.

>
>> But - are you sure you see a freeze, i.e. you can't, don't know, C-x C-c
>> or C-g or whatever else? That's not what I see with emacs -nw -Q, I see
>> an empty log window.
>
> Yes, you're right, technically Emacs does not freeze here, but it does
> nothing about the started git process (which can be seen in M-x
> list-processes), the same even with "M-& echo foo RET" - just blank
> screen.  With M-x gnus I was able to C-g, but otherwise it just hanged -
> that's what I interpreted as related to this thread/commit.  Anyway it
> seems ok with your fix now.

Ok. Thanks for testing!