Package: emacs;
Reported by: Alan Third <alan <at> idiocy.org>
Date: Mon, 4 Jan 2021 17:32:01 UTC
Severity: normal
Tags: moreinfo
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45658 in the body.
You can then email your comments to 45658 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
help-debbugs <at> gnu.org:bug#45658; Package debbugs.gnu.org.
(Mon, 04 Jan 2021 17:32:01 GMT) Full text and rfc822 format available.Alan Third <alan <at> idiocy.org>:help-debbugs <at> gnu.org.
(Mon, 04 Jan 2021 17:32:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Subject: Infinite loop in run loop on macOS Date: Mon, 4 Jan 2021 17:31:06 +0000
On Mon, Jan 04, 2021 at 02:51:31AM +0000, Jimmy Yuen Ho Wong wrote: > On Fri, Jan 1, 2021 at 10:41 AM Alan Third <alan <at> idiocy.org> wrote: > > > > On Fri, Jan 01, 2021 at 03:26:46AM +0000, Jimmy Yuen Ho Wong wrote: > > > I've just seen show up on the emacs-27 branch. I'm seeing the exact same > > > stack trace. However, I'm unable to confirm the two funcalls actually > > > correspond to "mouse-fixup-help-message" and "mouse-pixel-position", as I > > > don't know which commands in LLDB to type. Any help with this will be > > > appreciated. > > > > > > I don't know how to reproduce this consistently, but it seems to happen most > > > often after I cmd-tab to a different app's window from Emacs. > > > > Hi, it's probably bug#45541 which I've just pushed a fix for to the > > emacs-27 branch. > > Hi Alan, > > So instead of crashing at `ns_mouse_position`, it now freezes at > `ns_select`. Although I was able to send a USR2, I wasn't able to > debug on the LISP side since my entire Emacs froze with a spinning > beach ball. Please let me know if there's anyway I can debug this > further as I'm not too familiar with LLDB. Is this still mostly when you switch away from Emacs? Can you do "bt all" and send the whole output? -- Alan Third
Glenn Morris <rgm <at> gnu.org>
to control <at> debbugs.gnu.org.
(Mon, 04 Jan 2021 19:38:01 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Wed, 06 Jan 2021 18:54:02 GMT) Full text and rfc822 format available.Message #10 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Cc: 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Wed, 6 Jan 2021 18:53:41 +0000
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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Sat, 09 Jan 2021 23:23:01 GMT) Full text and rfc822 format available.Message #13 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> To: Alan Third <alan <at> idiocy.org>, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>, 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Sat, 9 Jan 2021 23:21:48 +0000
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 <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Sat, 09 Jan 2021 23:35:01 GMT) Full text and rfc822 format available.Message #16 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> To: Alan Third <alan <at> idiocy.org>, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>, 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Sat, 9 Jan 2021 23:33:26 +0000
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 <at> 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 <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Sun, 10 Jan 2021 00:02:01 GMT) Full text and rfc822 format available.Message #19 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Cc: 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Sun, 10 Jan 2021 00:01:31 +0000
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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Sun, 10 Jan 2021 00:48:02 GMT) Full text and rfc822 format available.Message #22 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> To: Alan Third <alan <at> idiocy.org>, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>, 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Sun, 10 Jan 2021 00:46:23 +0000
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 <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Sun, 10 Jan 2021 10:29:02 GMT) Full text and rfc822 format available.Message #25 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Cc: 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Sun, 10 Jan 2021 10:28:28 +0000
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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Thu, 14 Jan 2021 09:54:01 GMT) Full text and rfc822 format available.Message #28 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> To: Alan Third <alan <at> idiocy.org>, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>, 45658 <at> debbugs.gnu.org Subject: Re: Infinite loop in run loop on macOS Date: Thu, 14 Jan 2021 09:52:55 +0000
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 <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Wed, 20 Oct 2021 02:03:01 GMT) Full text and rfc822 format available.Message #31 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Alan Third <alan <at> idiocy.org> Cc: 45658 <at> debbugs.gnu.org, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Subject: Re: bug#45658: Infinite loop in run loop on macOS Date: Wed, 20 Oct 2021 10:02:23 +0800
Alan Third <alan <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Wed, 20 Oct 2021 20:25:01 GMT) Full text and rfc822 format available.Message #34 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Po Lu <luangruo <at> yahoo.com> Cc: 45658 <at> debbugs.gnu.org, Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Subject: Re: bug#45658: Infinite loop in run loop on macOS Date: Wed, 20 Oct 2021 21:24:44 +0100
On Wed, Oct 20, 2021 at 10:02:23AM +0800, Po Lu wrote: > Alan Third <alan <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Wed, 20 Oct 2021 20:40:02 GMT) Full text and rfc822 format available.Message #37 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> To: Alan Third <alan <at> idiocy.org> Cc: Po Lu <luangruo <at> yahoo.com>, 45658 <at> debbugs.gnu.org Subject: Re: bug#45658: Infinite loop in run loop on macOS Date: Wed, 20 Oct 2021 21:39:10 +0100
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 <at> idiocy.org> wrote: > On Wed, Oct 20, 2021 at 10:02:23AM +0800, Po Lu wrote: >> Alan Third <alan <at> 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-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Mon, 31 Jan 2022 17:20:01 GMT) Full text and rfc822 format available.Message #40 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, 45658 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org> Subject: Re: bug#45658: Infinite loop in run loop on macOS Date: Mon, 31 Jan 2022 18:19:30 +0100
Jimmy Yuen Ho Wong <wyuenho <at> 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
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org.
(Mon, 31 Jan 2022 17:20:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#45658; Package emacs.
(Tue, 01 Mar 2022 15:46:01 GMT) Full text and rfc822 format available.Message #45 received at 45658 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> Cc: Po Lu <luangruo <at> yahoo.com>, 45658 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org> Subject: Re: bug#45658: Infinite loop in run loop on macOS Date: Tue, 01 Mar 2022 16:45:11 +0100
Lars Ingebrigtsen <larsi <at> 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
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org.
(Tue, 01 Mar 2022 15:46:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 30 Mar 2022 11:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.