* bug#45658: Infinite loop in run loop on macOS [not found] ` <CAKDRQS40rKnNmTqbJM97OETfCKnz=5EvUNf1pDZiEWx-iD6+Yw@mail.gmail.com> @ 2021-01-06 18:53 ` Alan Third 2021-01-09 23:21 ` Jimmy Yuen Ho Wong 2021-10-20 2:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 2 replies; 12+ messages in thread From: Alan Third @ 2021-01-06 18:53 UTC (permalink / raw) To: Jimmy Yuen Ho Wong; +Cc: 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-06 18:53 ` bug#45658: Infinite loop in run loop on macOS Alan Third @ 2021-01-09 23:21 ` Jimmy Yuen Ho Wong 2021-01-09 23:33 ` Jimmy Yuen Ho Wong 2021-01-10 0:01 ` Alan Third 2021-10-20 2:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 2 replies; 12+ messages in thread From: Jimmy Yuen Ho Wong @ 2021-01-09 23:21 UTC (permalink / raw) To: Alan Third, Jimmy Yuen Ho Wong, 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-09 23:21 ` Jimmy Yuen Ho Wong @ 2021-01-09 23:33 ` Jimmy Yuen Ho Wong 2021-01-10 0:01 ` Alan Third 1 sibling, 0 replies; 12+ messages in thread From: Jimmy Yuen Ho Wong @ 2021-01-09 23:33 UTC (permalink / raw) To: Alan Third, Jimmy Yuen Ho Wong, 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-09 23:21 ` Jimmy Yuen Ho Wong 2021-01-09 23:33 ` Jimmy Yuen Ho Wong @ 2021-01-10 0:01 ` Alan Third 2021-01-10 0:46 ` Jimmy Yuen Ho Wong 1 sibling, 1 reply; 12+ messages in thread From: Alan Third @ 2021-01-10 0:01 UTC (permalink / raw) To: Jimmy Yuen Ho Wong; +Cc: 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-10 0:01 ` Alan Third @ 2021-01-10 0:46 ` Jimmy Yuen Ho Wong 2021-01-10 10:28 ` Alan Third 0 siblings, 1 reply; 12+ messages in thread From: Jimmy Yuen Ho Wong @ 2021-01-10 0:46 UTC (permalink / raw) To: Alan Third, Jimmy Yuen Ho Wong, 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-10 0:46 ` Jimmy Yuen Ho Wong @ 2021-01-10 10:28 ` Alan Third 2021-01-14 9:52 ` Jimmy Yuen Ho Wong 0 siblings, 1 reply; 12+ messages in thread From: Alan Third @ 2021-01-10 10:28 UTC (permalink / raw) To: Jimmy Yuen Ho Wong; +Cc: 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-10 10:28 ` Alan Third @ 2021-01-14 9:52 ` Jimmy Yuen Ho Wong 0 siblings, 0 replies; 12+ messages in thread From: Jimmy Yuen Ho Wong @ 2021-01-14 9:52 UTC (permalink / raw) To: Alan Third, Jimmy Yuen Ho Wong, 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-01-06 18:53 ` bug#45658: Infinite loop in run loop on macOS Alan Third 2021-01-09 23:21 ` Jimmy Yuen Ho Wong @ 2021-10-20 2:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-20 20:24 ` Alan Third 1 sibling, 1 reply; 12+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-20 2:02 UTC (permalink / raw) To: Alan Third; +Cc: 45658, Jimmy Yuen Ho Wong 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 :( ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-10-20 2:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-20 20:24 ` Alan Third 2021-10-20 20:39 ` Jimmy Yuen Ho Wong 0 siblings, 1 reply; 12+ messages in thread From: Alan Third @ 2021-10-20 20:24 UTC (permalink / raw) To: Po Lu; +Cc: 45658, Jimmy Yuen Ho Wong 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-10-20 20:24 ` Alan Third @ 2021-10-20 20:39 ` Jimmy Yuen Ho Wong 2022-01-31 17:19 ` Lars Ingebrigtsen 0 siblings, 1 reply; 12+ messages in thread From: Jimmy Yuen Ho Wong @ 2021-10-20 20:39 UTC (permalink / raw) To: Alan Third; +Cc: Po Lu, 45658 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2021-10-20 20:39 ` Jimmy Yuen Ho Wong @ 2022-01-31 17:19 ` Lars Ingebrigtsen 2022-03-01 15:45 ` Lars Ingebrigtsen 0 siblings, 1 reply; 12+ messages in thread From: Lars Ingebrigtsen @ 2022-01-31 17:19 UTC (permalink / raw) To: Jimmy Yuen Ho Wong; +Cc: Po Lu, 45658, Alan Third 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45658: Infinite loop in run loop on macOS 2022-01-31 17:19 ` Lars Ingebrigtsen @ 2022-03-01 15:45 ` Lars Ingebrigtsen 0 siblings, 0 replies; 12+ messages in thread From: Lars Ingebrigtsen @ 2022-03-01 15:45 UTC (permalink / raw) To: Jimmy Yuen Ho Wong; +Cc: Po Lu, 45658, Alan Third 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-03-01 15:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <e73a23d1-46b8-1542-5996-ca1afb5b0d30@gmail.com> [not found] ` <X+78YNyHEa36fYsp@breton.holly.idiocy.org> [not found] ` <CAKDRQS5eF0S2nk70mcW20yz_A8J36M=qtMwsTaV_wKWgTUZOwQ@mail.gmail.com> [not found] ` <X/NQ2mjwBp0+Ex+c@breton.holly.idiocy.org> [not found] ` <CAKDRQS40rKnNmTqbJM97OETfCKnz=5EvUNf1pDZiEWx-iD6+Yw@mail.gmail.com> 2021-01-06 18:53 ` bug#45658: Infinite loop in run loop on macOS Alan Third 2021-01-09 23:21 ` Jimmy Yuen Ho Wong 2021-01-09 23:33 ` Jimmy Yuen Ho Wong 2021-01-10 0:01 ` Alan Third 2021-01-10 0:46 ` Jimmy Yuen Ho Wong 2021-01-10 10:28 ` Alan Third 2021-01-14 9:52 ` Jimmy Yuen Ho Wong 2021-10-20 2:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-20 20:24 ` Alan Third 2021-10-20 20:39 ` Jimmy Yuen Ho Wong 2022-01-31 17:19 ` Lars Ingebrigtsen 2022-03-01 15:45 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.