bug#45658: Infinite loop in run loop on macOS

bug#45658: Infinite loop in run loop on macOS

[Alan Third]

On Wed, Jan 06, 2021 at 07:04:37AM +0000, Jimmy Yuen Ho Wong wrote:
> > Is this still mostly when you switch away from Emacs?
> 
> Yes. I'm on Catalina and here's my configure flags if that helps:
> 
> "--disable-silent-rules --prefix=/opt/local --with-ns --with-libgmp
> --with-json --with-xml2 --with-modules --with-lcms2 --with-rsvg
> --with-gnutls 'CFLAGS=-pipe -O0 -ggdb3
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> -arch x86_64' 'CPPFLAGS=-I/opt/local/include
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
> 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
> -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> -arch x86_64'"
> 
> > Can you do "bt all" and send the whole output?

Thanks. I've raised a bug report for this. Unfortunately I can't see
what's causing this just now... My best guess is that there's a missed
ns_send_appdefined somewhere. Can you switch to the thread that's
running fd_handler and see what it's doing? There are only two
branches, so it should be easy to work out which one is in use.

> (lldb) bt all
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
>     frame #1: 0x00007fff6a0cd1fd libsystem_kernel.dylib`mach_msg + 201
>     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
>     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
>     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
>     frame #5: 0x00007fff2eb06abd HIToolbox`RunCurrentEventLoopInMode + 292
>     frame #6: 0x00007fff2eb067d5 HIToolbox`ReceiveNextEventCommon + 584
>     frame #7: 0x00007fff2eb06579
> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
>     frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
>     frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
>     frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
>     frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
> run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
>     frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
> readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
> exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
> sigmask=0x0000000000000000) at nsterm.m:4690:3
>     frame #13: 0x00000001002f567a
> Emacs`wait_reading_process_output(time_limit=10, nsecs=0, read_kbd=-1,
> do_display=true, wait_for_cell=0x0000000000000000,
> wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5577:18
>     frame #14: 0x0000000100010bfe
> Emacs`sit_for(timeout=0x000000000000002a, reading=true,
> display_option=1) at dispnew.c:6064:3
>     frame #15: 0x0000000100173432 Emacs`read_char(commandflag=1,
> map=0x00000001de6881f3, prev_event=0x0000000000000000,
> used_mouse_menu=0x00007ffeefbfdddf, end_time=0x0000000000000000) at
> keyboard.c:2738:11
>     frame #16: 0x000000010016e569
> Emacs`read_key_sequence(keybuf=0x00007ffeefbfe0e0,
> prompt=0x0000000000000000, dont_downcase_last=false,
> can_return_switch_frame=true, fix_current_buffer=true,
> prevent_redisplay=false) at keyboard.c:9554:12
>     frame #17: 0x000000010016cf89 Emacs`command_loop_1 at keyboard.c:1350:15
>     frame #18: 0x0000000100269a9f
> Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at
> keyboard.c:1236), handlers=0x0000000000000090, hfun=(Emacs`cmd_error
> at keyboard.c:919)) at eval.c:1356:25
>     frame #19: 0x0000000100184cdc
> Emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
>     frame #20: 0x000000010026940a
> Emacs`internal_catch(tag=0x000000000000c840,
> func=(Emacs`command_loop_2 at keyboard.c:1087),
> arg=0x0000000000000000) at eval.c:1117:25
>     frame #21: 0x000000010016bf1a Emacs`command_loop at keyboard.c:1070:2
>     frame #22: 0x000000010016bda0 Emacs`recursive_edit_1 at keyboard.c:714:9
>     frame #23: 0x000000010016c0e9 Emacs`Frecursive_edit at keyboard.c:786:3
>     frame #24: 0x00000001001695b4 Emacs`main(argc=1,
> argv=0x00007ffeefbfe690) at emacs.c:2066:3
>     frame #25: 0x00007fff69f8bcc9 libdyld.dylib`start + 1
>   thread #4, name = 'gmain'
>     frame #0: 0x00007fff6a0d50fe libsystem_kernel.dylib`__select + 10
>     frame #1: 0x0000000102045174 libglib-2.0.0.dylib`g_poll + 546
>     frame #2: 0x0000000102038f63
> libglib-2.0.0.dylib`g_main_context_iterate + 340
>     frame #3: 0x0000000102039011
> libglib-2.0.0.dylib`g_main_context_iteration + 55
>     frame #4: 0x000000010203a0c1 libglib-2.0.0.dylib`glib_worker_main + 30
>     frame #5: 0x000000010205a844 libglib-2.0.0.dylib`g_thread_proxy + 90
>     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
>     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
>   thread #7
>     frame #0: 0x00007fff6a0d187e libsystem_kernel.dylib`__pselect + 10
>     frame #1: 0x00007fff6a0d179b
> libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
>     frame #2: 0x000000010036def3 Emacs`-[EmacsApp
> fd_handler:](self=0x000000010525e180, _cmd="fd_handler:",
> unused=0x0000000000000000) at nsterm.m:6100:20
>     frame #3: 0x00007fff3256d7b2 Foundation`__NSThread__start__ + 1064
>     frame #4: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
>     frame #5: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
>   thread #11, name = 'com.apple.NSEventThread'
>     frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
>     frame #1: 0x00007fff6a0cd170 libsystem_kernel.dylib`mach_msg + 60
>     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
>     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
>     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
>     frame #5: 0x00007fff2d2ed954 AppKit`_NSEventThread + 132
>     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
>     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
>   thread #127
>     frame #0: 0x00007fff6a0ce4ce libsystem_kernel.dylib`__workq_kernreturn + 10
>     frame #1: 0x00007fff6a18caa1 libsystem_pthread.dylib`_pthread_wqthread + 390
>     frame #2: 0x00007fff6a18bb77 libsystem_pthread.dylib`start_wqthread + 15

-- 
Alan Third

bug#45658: Infinite loop in run loop on macOS

[Jimmy Yuen Ho Wong]

Ok I've just reproduced this again, this time simply by opening a file
in the terminal with emacsclient, in the hope Emacs.app will open it.
I've switched to the thread running fd_handler (nsterm.m:6100:20
right?) This is the frame variables:

(EmacsApp *) self = 0x0000000105425d00
(SEL) _cmd = "fd_handler:"
(id) unused = nil
(int) result = 1
(int) waiting = 0
(int) nfds = 31
(char) c = 'g'
(fd_set) readfds = {
  fds_bits = {
    [0] = 0
    [1] = 0
    [2] = 0
    [3] = 0
    [4] = 0
    [5] = 0
    [6] = 0
    [7] = 0
    [8] = 0
    [9] = 0
    [10] = 0
    [11] = 0
    [12] = 0
    [13] = 0
    [14] = 0
    [15] = 0
    [16] = 0
    [17] = 0
    [18] = 0
    [19] = 0
    [20] = 0
    [21] = 0
    [22] = 0
    [23] = 0
    [24] = 0
    [25] = 0
    [26] = 0
    [27] = 0
    [28] = 0
    [29] = 0
    [30] = 0
    [31] = 0
  }
}
(fd_set) writefds = {
  fds_bits = {
    [0] = 0
    [1] = 0
    [2] = 0
    [3] = 0
    [4] = 0
    [5] = 0
    [6] = 0
    [7] = 0
    [8] = 0
    [9] = 0
    [10] = 0
    [11] = 0
    [12] = 0
    [13] = 0
    [14] = 0
    [15] = 0
    [16] = 0
    [17] = 0
    [18] = 0
    [19] = 0
    [20] = 0
    [21] = 0
    [22] = 0
    [23] = 0
    [24] = 0
    [25] = 0
    [26] = 0
    [27] = 0
    [28] = 0
    [29] = 0
    [30] = 0
    [31] = 0
  }
}
(fd_set *) wfds = 0x000070000fbc0c18
(timespec) timeout = (tv_sec = 4, tv_nsec = 994588000)
(timespec *) tmo = 0x000070000fbc0c00
(NSAutoreleasePool *) pool = 0x00000001051db650


Jimmy

On Wed, Jan 6, 2021 at 6:53 PM Alan Third <alan@idiocy.org> wrote:
>
> On Wed, Jan 06, 2021 at 07:04:37AM +0000, Jimmy Yuen Ho Wong wrote:
> > > Is this still mostly when you switch away from Emacs?
> >
> > Yes. I'm on Catalina and here's my configure flags if that helps:
> >
> > "--disable-silent-rules --prefix=/opt/local --with-ns --with-libgmp
> > --with-json --with-xml2 --with-modules --with-lcms2 --with-rsvg
> > --with-gnutls 'CFLAGS=-pipe -O0 -ggdb3
> > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> > -arch x86_64' 'CPPFLAGS=-I/opt/local/include
> > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
> > 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
> > -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> > -arch x86_64'"
> >
> > > Can you do "bt all" and send the whole output?
>
> Thanks. I've raised a bug report for this. Unfortunately I can't see
> what's causing this just now... My best guess is that there's a missed
> ns_send_appdefined somewhere. Can you switch to the thread that's
> running fd_handler and see what it's doing? There are only two
> branches, so it should be easy to work out which one is in use.
>
> > (lldb) bt all
> >
> > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> >   * frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
> >     frame #1: 0x00007fff6a0cd1fd libsystem_kernel.dylib`mach_msg + 201
> >     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
> >     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
> >     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
> >     frame #5: 0x00007fff2eb06abd HIToolbox`RunCurrentEventLoopInMode + 292
> >     frame #6: 0x00007fff2eb067d5 HIToolbox`ReceiveNextEventCommon + 584
> >     frame #7: 0x00007fff2eb06579
> > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
> >     frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
> >     frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
> > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
> >     frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
> >     frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
> > run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
> >     frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
> > readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
> > exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
> > sigmask=0x0000000000000000) at nsterm.m:4690:3
> >     frame #13: 0x00000001002f567a
> > Emacs`wait_reading_process_output(time_limit=10, nsecs=0, read_kbd=-1,
> > do_display=true, wait_for_cell=0x0000000000000000,
> > wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5577:18
> >     frame #14: 0x0000000100010bfe
> > Emacs`sit_for(timeout=0x000000000000002a, reading=true,
> > display_option=1) at dispnew.c:6064:3
> >     frame #15: 0x0000000100173432 Emacs`read_char(commandflag=1,
> > map=0x00000001de6881f3, prev_event=0x0000000000000000,
> > used_mouse_menu=0x00007ffeefbfdddf, end_time=0x0000000000000000) at
> > keyboard.c:2738:11
> >     frame #16: 0x000000010016e569
> > Emacs`read_key_sequence(keybuf=0x00007ffeefbfe0e0,
> > prompt=0x0000000000000000, dont_downcase_last=false,
> > can_return_switch_frame=true, fix_current_buffer=true,
> > prevent_redisplay=false) at keyboard.c:9554:12
> >     frame #17: 0x000000010016cf89 Emacs`command_loop_1 at keyboard.c:1350:15
> >     frame #18: 0x0000000100269a9f
> > Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at
> > keyboard.c:1236), handlers=0x0000000000000090, hfun=(Emacs`cmd_error
> > at keyboard.c:919)) at eval.c:1356:25
> >     frame #19: 0x0000000100184cdc
> > Emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
> >     frame #20: 0x000000010026940a
> > Emacs`internal_catch(tag=0x000000000000c840,
> > func=(Emacs`command_loop_2 at keyboard.c:1087),
> > arg=0x0000000000000000) at eval.c:1117:25
> >     frame #21: 0x000000010016bf1a Emacs`command_loop at keyboard.c:1070:2
> >     frame #22: 0x000000010016bda0 Emacs`recursive_edit_1 at keyboard.c:714:9
> >     frame #23: 0x000000010016c0e9 Emacs`Frecursive_edit at keyboard.c:786:3
> >     frame #24: 0x00000001001695b4 Emacs`main(argc=1,
> > argv=0x00007ffeefbfe690) at emacs.c:2066:3
> >     frame #25: 0x00007fff69f8bcc9 libdyld.dylib`start + 1
> >   thread #4, name = 'gmain'
> >     frame #0: 0x00007fff6a0d50fe libsystem_kernel.dylib`__select + 10
> >     frame #1: 0x0000000102045174 libglib-2.0.0.dylib`g_poll + 546
> >     frame #2: 0x0000000102038f63
> > libglib-2.0.0.dylib`g_main_context_iterate + 340
> >     frame #3: 0x0000000102039011
> > libglib-2.0.0.dylib`g_main_context_iteration + 55
> >     frame #4: 0x000000010203a0c1 libglib-2.0.0.dylib`glib_worker_main + 30
> >     frame #5: 0x000000010205a844 libglib-2.0.0.dylib`g_thread_proxy + 90
> >     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> >     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> >   thread #7
> >     frame #0: 0x00007fff6a0d187e libsystem_kernel.dylib`__pselect + 10
> >     frame #1: 0x00007fff6a0d179b
> > libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
> >     frame #2: 0x000000010036def3 Emacs`-[EmacsApp
> > fd_handler:](self=0x000000010525e180, _cmd="fd_handler:",
> > unused=0x0000000000000000) at nsterm.m:6100:20
> >     frame #3: 0x00007fff3256d7b2 Foundation`__NSThread__start__ + 1064
> >     frame #4: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> >     frame #5: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> >   thread #11, name = 'com.apple.NSEventThread'
> >     frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
> >     frame #1: 0x00007fff6a0cd170 libsystem_kernel.dylib`mach_msg + 60
> >     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
> >     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
> >     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
> >     frame #5: 0x00007fff2d2ed954 AppKit`_NSEventThread + 132
> >     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> >     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> >   thread #127
> >     frame #0: 0x00007fff6a0ce4ce libsystem_kernel.dylib`__workq_kernreturn + 10
> >     frame #1: 0x00007fff6a18caa1 libsystem_pthread.dylib`_pthread_wqthread + 390
> >     frame #2: 0x00007fff6a18bb77 libsystem_pthread.dylib`start_wqthread + 15
>
> --
> Alan Third

bug#45658: Infinite loop in run loop on macOS

[Jimmy Yuen Ho Wong]

Missed a variable in the last reply

(fd_set) fds = {
  fds_bits = {
    [0] = 32
    [1] = 0
    [2] = 0
    [3] = 0
    [4] = 0
    [5] = 0
    [6] = 0
    [7] = 0
    [8] = 0
    [9] = 0
    [10] = 0
    [11] = 0
    [12] = 0
    [13] = 0
    [14] = 0
    [15] = 0
    [16] = 0
    [17] = 0
    [18] = 0
    [19] = 0
    [20] = 0
    [21] = 0
    [22] = 0
    [23] = 0
    [24] = 0
    [25] = 0
    [26] = 0
    [27] = 0
    [28] = 0
    [29] = 0
    [30] = 0
    [31] = 0
  }
}

Jimmy

On Sat, Jan 9, 2021 at 11:21 PM Jimmy Yuen Ho Wong <wyuenho@gmail.com> wrote:
>
> Ok I've just reproduced this again, this time simply by opening a file
> in the terminal with emacsclient, in the hope Emacs.app will open it.
> I've switched to the thread running fd_handler (nsterm.m:6100:20
> right?) This is the frame variables:
>
> (EmacsApp *) self = 0x0000000105425d00
> (SEL) _cmd = "fd_handler:"
> (id) unused = nil
> (int) result = 1
> (int) waiting = 0
> (int) nfds = 31
> (char) c = 'g'
> (fd_set) readfds = {
>   fds_bits = {
>     [0] = 0
>     [1] = 0
>     [2] = 0
>     [3] = 0
>     [4] = 0
>     [5] = 0
>     [6] = 0
>     [7] = 0
>     [8] = 0
>     [9] = 0
>     [10] = 0
>     [11] = 0
>     [12] = 0
>     [13] = 0
>     [14] = 0
>     [15] = 0
>     [16] = 0
>     [17] = 0
>     [18] = 0
>     [19] = 0
>     [20] = 0
>     [21] = 0
>     [22] = 0
>     [23] = 0
>     [24] = 0
>     [25] = 0
>     [26] = 0
>     [27] = 0
>     [28] = 0
>     [29] = 0
>     [30] = 0
>     [31] = 0
>   }
> }
> (fd_set) writefds = {
>   fds_bits = {
>     [0] = 0
>     [1] = 0
>     [2] = 0
>     [3] = 0
>     [4] = 0
>     [5] = 0
>     [6] = 0
>     [7] = 0
>     [8] = 0
>     [9] = 0
>     [10] = 0
>     [11] = 0
>     [12] = 0
>     [13] = 0
>     [14] = 0
>     [15] = 0
>     [16] = 0
>     [17] = 0
>     [18] = 0
>     [19] = 0
>     [20] = 0
>     [21] = 0
>     [22] = 0
>     [23] = 0
>     [24] = 0
>     [25] = 0
>     [26] = 0
>     [27] = 0
>     [28] = 0
>     [29] = 0
>     [30] = 0
>     [31] = 0
>   }
> }
> (fd_set *) wfds = 0x000070000fbc0c18
> (timespec) timeout = (tv_sec = 4, tv_nsec = 994588000)
> (timespec *) tmo = 0x000070000fbc0c00
> (NSAutoreleasePool *) pool = 0x00000001051db650
>
>
> Jimmy
>
> On Wed, Jan 6, 2021 at 6:53 PM Alan Third <alan@idiocy.org> wrote:
> >
> > On Wed, Jan 06, 2021 at 07:04:37AM +0000, Jimmy Yuen Ho Wong wrote:
> > > > Is this still mostly when you switch away from Emacs?
> > >
> > > Yes. I'm on Catalina and here's my configure flags if that helps:
> > >
> > > "--disable-silent-rules --prefix=/opt/local --with-ns --with-libgmp
> > > --with-json --with-xml2 --with-modules --with-lcms2 --with-rsvg
> > > --with-gnutls 'CFLAGS=-pipe -O0 -ggdb3
> > > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> > > -arch x86_64' 'CPPFLAGS=-I/opt/local/include
> > > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
> > > 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
> > > -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
> > > -arch x86_64'"
> > >
> > > > Can you do "bt all" and send the whole output?
> >
> > Thanks. I've raised a bug report for this. Unfortunately I can't see
> > what's causing this just now... My best guess is that there's a missed
> > ns_send_appdefined somewhere. Can you switch to the thread that's
> > running fd_handler and see what it's doing? There are only two
> > branches, so it should be easy to work out which one is in use.
> >
> > > (lldb) bt all
> > >
> > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> > >   * frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
> > >     frame #1: 0x00007fff6a0cd1fd libsystem_kernel.dylib`mach_msg + 201
> > >     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
> > >     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
> > >     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
> > >     frame #5: 0x00007fff2eb06abd HIToolbox`RunCurrentEventLoopInMode + 292
> > >     frame #6: 0x00007fff2eb067d5 HIToolbox`ReceiveNextEventCommon + 584
> > >     frame #7: 0x00007fff2eb06579
> > > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
> > >     frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
> > >     frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
> > > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
> > >     frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
> > >     frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
> > > run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
> > >     frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
> > > readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
> > > exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
> > > sigmask=0x0000000000000000) at nsterm.m:4690:3
> > >     frame #13: 0x00000001002f567a
> > > Emacs`wait_reading_process_output(time_limit=10, nsecs=0, read_kbd=-1,
> > > do_display=true, wait_for_cell=0x0000000000000000,
> > > wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5577:18
> > >     frame #14: 0x0000000100010bfe
> > > Emacs`sit_for(timeout=0x000000000000002a, reading=true,
> > > display_option=1) at dispnew.c:6064:3
> > >     frame #15: 0x0000000100173432 Emacs`read_char(commandflag=1,
> > > map=0x00000001de6881f3, prev_event=0x0000000000000000,
> > > used_mouse_menu=0x00007ffeefbfdddf, end_time=0x0000000000000000) at
> > > keyboard.c:2738:11
> > >     frame #16: 0x000000010016e569
> > > Emacs`read_key_sequence(keybuf=0x00007ffeefbfe0e0,
> > > prompt=0x0000000000000000, dont_downcase_last=false,
> > > can_return_switch_frame=true, fix_current_buffer=true,
> > > prevent_redisplay=false) at keyboard.c:9554:12
> > >     frame #17: 0x000000010016cf89 Emacs`command_loop_1 at keyboard.c:1350:15
> > >     frame #18: 0x0000000100269a9f
> > > Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at
> > > keyboard.c:1236), handlers=0x0000000000000090, hfun=(Emacs`cmd_error
> > > at keyboard.c:919)) at eval.c:1356:25
> > >     frame #19: 0x0000000100184cdc
> > > Emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
> > >     frame #20: 0x000000010026940a
> > > Emacs`internal_catch(tag=0x000000000000c840,
> > > func=(Emacs`command_loop_2 at keyboard.c:1087),
> > > arg=0x0000000000000000) at eval.c:1117:25
> > >     frame #21: 0x000000010016bf1a Emacs`command_loop at keyboard.c:1070:2
> > >     frame #22: 0x000000010016bda0 Emacs`recursive_edit_1 at keyboard.c:714:9
> > >     frame #23: 0x000000010016c0e9 Emacs`Frecursive_edit at keyboard.c:786:3
> > >     frame #24: 0x00000001001695b4 Emacs`main(argc=1,
> > > argv=0x00007ffeefbfe690) at emacs.c:2066:3
> > >     frame #25: 0x00007fff69f8bcc9 libdyld.dylib`start + 1
> > >   thread #4, name = 'gmain'
> > >     frame #0: 0x00007fff6a0d50fe libsystem_kernel.dylib`__select + 10
> > >     frame #1: 0x0000000102045174 libglib-2.0.0.dylib`g_poll + 546
> > >     frame #2: 0x0000000102038f63
> > > libglib-2.0.0.dylib`g_main_context_iterate + 340
> > >     frame #3: 0x0000000102039011
> > > libglib-2.0.0.dylib`g_main_context_iteration + 55
> > >     frame #4: 0x000000010203a0c1 libglib-2.0.0.dylib`glib_worker_main + 30
> > >     frame #5: 0x000000010205a844 libglib-2.0.0.dylib`g_thread_proxy + 90
> > >     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> > >     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> > >   thread #7
> > >     frame #0: 0x00007fff6a0d187e libsystem_kernel.dylib`__pselect + 10
> > >     frame #1: 0x00007fff6a0d179b
> > > libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
> > >     frame #2: 0x000000010036def3 Emacs`-[EmacsApp
> > > fd_handler:](self=0x000000010525e180, _cmd="fd_handler:",
> > > unused=0x0000000000000000) at nsterm.m:6100:20
> > >     frame #3: 0x00007fff3256d7b2 Foundation`__NSThread__start__ + 1064
> > >     frame #4: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> > >     frame #5: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> > >   thread #11, name = 'com.apple.NSEventThread'
> > >     frame #0: 0x00007fff6a0ccdfa libsystem_kernel.dylib`mach_msg_trap + 10
> > >     frame #1: 0x00007fff6a0cd170 libsystem_kernel.dylib`mach_msg + 60
> > >     frame #2: 0x00007fff2fedbef5 CoreFoundation`__CFRunLoopServiceMachPort + 247
> > >     frame #3: 0x00007fff2feda9c2 CoreFoundation`__CFRunLoopRun + 1319
> > >     frame #4: 0x00007fff2fed9e3e CoreFoundation`CFRunLoopRunSpecific + 462
> > >     frame #5: 0x00007fff2d2ed954 AppKit`_NSEventThread + 132
> > >     frame #6: 0x00007fff6a190109 libsystem_pthread.dylib`_pthread_start + 148
> > >     frame #7: 0x00007fff6a18bb8b libsystem_pthread.dylib`thread_start + 15
> > >   thread #127
> > >     frame #0: 0x00007fff6a0ce4ce libsystem_kernel.dylib`__workq_kernreturn + 10
> > >     frame #1: 0x00007fff6a18caa1 libsystem_pthread.dylib`_pthread_wqthread + 390
> > >     frame #2: 0x00007fff6a18bb77 libsystem_pthread.dylib`start_wqthread + 15
> >
> > --
> > Alan Third

bug#45658: Infinite loop in run loop on macOS

[Alan Third]

On Sat, Jan 09, 2021 at 11:21:48PM +0000, Jimmy Yuen Ho Wong wrote:
> Ok I've just reproduced this again, this time simply by opening a file
> in the terminal with emacsclient, in the hope Emacs.app will open it.
> I've switched to the thread running fd_handler (nsterm.m:6100:20
> right?) This is the frame variables:

That all looks pretty much like I'd expect.

Can you check if it ever reaches the end of ns_select? You could
either stick a breakpoint at, say, like 4733 of nsterm.m, or make it
print to the console or whatever.

I suspect that since you're seeing a spinning wheel it's not reaching
the end, but we may as well find out for sure.

You're running macOS 10.15, yes?

Do you use Homebrew or something else?

Does 'emacs -q' also freeze up?
-- 
Alan Third

bug#45658: Infinite loop in run loop on macOS

[Jimmy Yuen Ho Wong]

The breakpoint at 4733 does get reached, there's no beach ball for
this initially, just an unresponsive frame. I can't Cmd-TAB to it, I
have to use the mouse to select it in Mission Control. The windows
sometimes freeze, sometimes go blank then freeze. This bug can
occasionally be produced by issuing `EDITOR=emacsclient git rebase -i
HEAD~2` in the terminal, but not consistently.

I'm on Catalina, not on Homebrew, I just checked out the emacs repo
and switched to the emacs 27 branch. I'm on the latest commit.

> Does 'emacs -q' also freeze up

I don't have a way to reproduce this bug consistently so I don't know.

Jimmy

On Sun, Jan 10, 2021 at 12:01 AM Alan Third <alan@idiocy.org> wrote:
>
> On Sat, Jan 09, 2021 at 11:21:48PM +0000, Jimmy Yuen Ho Wong wrote:
> > Ok I've just reproduced this again, this time simply by opening a file
> > in the terminal with emacsclient, in the hope Emacs.app will open it.
> > I've switched to the thread running fd_handler (nsterm.m:6100:20
> > right?) This is the frame variables:
>
> That all looks pretty much like I'd expect.
>
> Can you check if it ever reaches the end of ns_select? You could
> either stick a breakpoint at, say, like 4733 of nsterm.m, or make it
> print to the console or whatever.
>
> I suspect that since you're seeing a spinning wheel it's not reaching
> the end, but we may as well find out for sure.
>
> You're running macOS 10.15, yes?
>
> Do you use Homebrew or something else?
>
> Does 'emacs -q' also freeze up?
> --
> Alan Third

bug#45658: Infinite loop in run loop on macOS

[Alan Third]

On Sun, Jan 10, 2021 at 12:46:23AM +0000, Jimmy Yuen Ho Wong wrote:
> The breakpoint at 4733 does get reached, there's no beach ball for
> this initially, just an unresponsive frame. I can't Cmd-TAB to it, I
> have to use the mouse to select it in Mission Control. The windows
> sometimes freeze, sometimes go blank then freeze. This bug can
> occasionally be produced by issuing `EDITOR=emacsclient git rebase -i
> HEAD~2` in the terminal, but not consistently.
> 
> I'm on Catalina, not on Homebrew, I just checked out the emacs repo
> and switched to the emacs 27 branch. I'm on the latest commit.

Out of interest, can you try using the master branch for a while and
see if the same thing happens there?
-- 
Alan Third

bug#45658: Infinite loop in run loop on macOS

[Jimmy Yuen Ho Wong]

I can't really use it. It's broken at least 4 packages I need to use
at the moment.

Jimmy

On Sun, Jan 10, 2021 at 10:28 AM Alan Third <alan@idiocy.org> wrote:
>
> On Sun, Jan 10, 2021 at 12:46:23AM +0000, Jimmy Yuen Ho Wong wrote:
> > The breakpoint at 4733 does get reached, there's no beach ball for
> > this initially, just an unresponsive frame. I can't Cmd-TAB to it, I
> > have to use the mouse to select it in Mission Control. The windows
> > sometimes freeze, sometimes go blank then freeze. This bug can
> > occasionally be produced by issuing `EDITOR=emacsclient git rebase -i
> > HEAD~2` in the terminal, but not consistently.
> >
> > I'm on Catalina, not on Homebrew, I just checked out the emacs repo
> > and switched to the emacs 27 branch. I'm on the latest commit.
>
> Out of interest, can you try using the master branch for a while and
> see if the same thing happens there?
> --
> Alan Third

bug#45658: Infinite loop in run loop on macOS

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Third <alan@idiocy.org> writes:

> ns_send_appdefined somewhere. Can you switch to the thread that's
> running fd_handler and see what it's doing? There are only two
> branches, so it should be easy to work out which one is in use.

>>     frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
>>     frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
>> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
>>     frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
>>     frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
>> run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
>>     frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
>> readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
>> exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
>> sigmask=0x0000000000000000) at nsterm.m:4690:3

Does it also make sense for this to occur on GNUstep?  I have just seen
a very similar bug there, but I lost the backtrace :(

bug#45658: Infinite loop in run loop on macOS

[Alan Third]

On Wed, Oct 20, 2021 at 10:02:23AM +0800, Po Lu wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > ns_send_appdefined somewhere. Can you switch to the thread that's
> > running fd_handler and see what it's doing? There are only two
> > branches, so it should be easy to work out which one is in use.
> 
> >>     frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
> >>     frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
> >> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
> >>     frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
> >>     frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
> >> run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
> >>     frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
> >> readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
> >> exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
> >> sigmask=0x0000000000000000) at nsterm.m:4690:3
> 
> Does it also make sense for this to occur on GNUstep?  I have just seen
> a very similar bug there, but I lost the backtrace :(

It doesn't make any sense to me for it to happen anywhere. ;)

If it happens on macOS I don't see why it shouldn't happen on GNUstep,
unless it's a bug in Cocoa and not in GNUstep. I wasn't able to
replicate the crash and I don't have any real clue what was causing it
for Jimmy.
-- 
Alan Third

bug#45658: Infinite loop in run loop on macOS

[Jimmy Yuen Ho Wong]

I haven't seen this for quite some time now, but then I've switched to emacs 28 some time ago too. I'm not sure if it's still a problem on emacs 27.

> On 20 Oct 2021, at 9:24 pm, Alan Third <alan@idiocy.org> wrote:
> On Wed, Oct 20, 2021 at 10:02:23AM +0800, Po Lu wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>>> ns_send_appdefined somewhere. Can you switch to the thread that's
>>> running fd_handler and see what it's doing? There are only two
>>> branches, so it should be easy to work out which one is in use.
>> 
>>>>    frame #8: 0x00007fff2d14c039 AppKit`_DPSNextEvent + 883
>>>>    frame #9: 0x00007fff2d14a880 AppKit`-[NSApplication(NSEvent)
>>>> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
>>>>    frame #10: 0x00007fff2d13c58e AppKit`-[NSApplication run] + 658
>>>>    frame #11: 0x000000010036c5fa Emacs`-[EmacsApp
>>>> run](self=0x000000010525e180, _cmd="run") at nsterm.m:5602:9
>>>>    frame #12: 0x000000010036a8eb Emacs`ns_select(nfds=30,
>>>> readfds=0x00007ffeefbfd1f0, writefds=0x00007ffeefbfd170,
>>>> exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd148,
>>>> sigmask=0x0000000000000000) at nsterm.m:4690:3
>> 
>> Does it also make sense for this to occur on GNUstep?  I have just seen
>> a very similar bug there, but I lost the backtrace :(
> 
> It doesn't make any sense to me for it to happen anywhere. ;)
> 
> If it happens on macOS I don't see why it shouldn't happen on GNUstep,
> unless it's a bug in Cocoa and not in GNUstep. I wasn't able to
> replicate the crash and I don't have any real clue what was causing it
> for Jimmy.
> -- 
> Alan Third

bug#45658: Infinite loop in run loop on macOS

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I haven't seen this for quite some time now, but then I've switched to
> emacs 28 some time ago too. I'm not sure if it's still a problem on
> emacs 27.

Does this mean that the problem has gone away for you (in Emacs 28)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45658: Infinite loop in run loop on macOS

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I haven't seen this for quite some time now, but then I've switched to
>> emacs 28 some time ago too. I'm not sure if it's still a problem on
>> emacs 27.
>
> Does this mean that the problem has gone away for you (in Emacs 28)?

This was a month ago, so I assume that the problem went away, and I'm
closing this bug report.  If there's still an issue here, please respond
to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no