* [emacs-master] Frequent freezes on macOS @ 2021-01-19 6:44 Pankaj Jangid 2021-01-19 9:28 ` Herbert J. Skuhra 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Jangid @ 2021-01-19 6:44 UTC (permalink / raw) To: emacs-devel Emacs (master branch) is frequently going into freezes since last 4-5 days. It is happening at random. So, I don’t have a recipe as of now. Sometimes in python-mode sometimes when I press ‘g’ inside Gnus group buffer to fetch new news. This is not happening when I use it without window system (emacs -nw). Please help me get started with some debugging. I am on macOS (Big Sur). I have created a debug build. CFLAGS="-O0 -g3" ./configure make But then I don’t know what to do next to get more information. When I used to program in C, after a crash I used gdb to get where it is happening. Here, emacs is not crashing. It just hangs. I tried to run emacs with debugger. I followed instructions in this old thread: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00216.html but there is no bootstrap-emacs on my system. How this is built? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 6:44 [emacs-master] Frequent freezes on macOS Pankaj Jangid @ 2021-01-19 9:28 ` Herbert J. Skuhra 2021-01-19 15:31 ` Pankaj Jangid 0 siblings, 1 reply; 9+ messages in thread From: Herbert J. Skuhra @ 2021-01-19 9:28 UTC (permalink / raw) To: emacs-devel On Tue, Jan 19, 2021 at 06:44:45AM +0000, Pankaj Jangid wrote: > Emacs (master branch) is frequently going into freezes since last 4-5 > days. It is happening at random. So, I don’t have a recipe as of > now. Sometimes in python-mode sometimes when I press ‘g’ inside Gnus > group buffer to fetch new news. I have the same issue. I think it started with the following commit: commit 8f0ce42d3eb9b212424a4a25a376287ffc94a73e Author: Philipp Stephani Date: Sun Jan 10 16:31:12 2021 +0100 > but there is no bootstrap-emacs on my system. How this is built? (g)make bootstrap ? Can you try: git checkout 8f0ce42d3eb9b212424a4a25a376287ffc94a73e gmake bootstrap If Emacs still freezes: git checkout master git checkout 66756df286bea6efd3f9a8290e38e8d77bdf0264 gmake bootstrap Does Emacs no longer freeze? -- Herbert ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 9:28 ` Herbert J. Skuhra @ 2021-01-19 15:31 ` Pankaj Jangid 2021-01-19 15:39 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Jangid @ 2021-01-19 15:31 UTC (permalink / raw) To: Herbert J. Skuhra; +Cc: emacs-devel "Herbert J. Skuhra" <herbert@gojira.at> writes: > On Tue, Jan 19, 2021 at 06:44:45AM +0000, Pankaj Jangid wrote: >> Emacs (master branch) is frequently going into freezes since last 4-5 >> days. It is happening at random. So, I don’t have a recipe as of >> now. Sometimes in python-mode sometimes when I press ‘g’ inside Gnus >> group buffer to fetch new news. > > I have the same issue. I think it started with the following commit: > > commit 8f0ce42d3eb9b212424a4a25a376287ffc94a73e > Author: Philipp Stephani > Date: Sun Jan 10 16:31:12 2021 +0100 > > Can you try: > > git checkout 8f0ce42d3eb9b212424a4a25a376287ffc94a73e > gmake bootstrap > > If Emacs still freezes: > > git checkout master > git checkout 66756df286bea6efd3f9a8290e38e8d77bdf0264 > gmake bootstrap > > Does Emacs no longer freeze? You are absolutely right. 8f0ce4 gives freezes and 66756d works fine. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 15:31 ` Pankaj Jangid @ 2021-01-19 15:39 ` Eli Zaretskii 2021-01-19 17:19 ` Doug Davis 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2021-01-19 15:39 UTC (permalink / raw) To: Pankaj Jangid; +Cc: herbert, emacs-devel > From: Pankaj Jangid <pankaj@codeisgreat.org> > Date: Tue, 19 Jan 2021 21:01:24 +0530 > Cc: emacs-devel@gnu.org > > > commit 8f0ce42d3eb9b212424a4a25a376287ffc94a73e > > Author: Philipp Stephani > > Date: Sun Jan 10 16:31:12 2021 +0100 > > > > Can you try: > > > > git checkout 8f0ce42d3eb9b212424a4a25a376287ffc94a73e > > gmake bootstrap > > > > If Emacs still freezes: > > > > git checkout master > > git checkout 66756df286bea6efd3f9a8290e38e8d77bdf0264 > > gmake bootstrap > > > > Does Emacs no longer freeze? > > You are absolutely right. 8f0ce4 gives freezes and 66756d works fine. Can you attach a debugger to Emacs when it freezes, and show the C-level backtrace? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 15:39 ` Eli Zaretskii @ 2021-01-19 17:19 ` Doug Davis 2021-01-19 18:09 ` Philipp Stephani 0 siblings, 1 reply; 9+ messages in thread From: Doug Davis @ 2021-01-19 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: herbert, Pankaj Jangid, emacs-devel I've been able to reproduce the crash. Eli Zaretskii <eliz@gnu.org> writes: > Can you attach a debugger to Emacs when it freezes, and show the > C-level backtrace? Here's my novice debugger attempt (apologies if it's not helpful); first after compiling with -O3 -g3: ddavis@charm ~/software/repos/emacs (HEAD detached at 8f0ce42d3e) $ lldb src/emacs (lldb) target create "src/emacs" Current executable set to '/Users/ddavis/software/repos/emacs/src/emacs' (arm64). (lldb) run Process 28189 launched: '/Users/ddavis/software/repos/emacs/src/emacs' (arm64) 2021-01-19 11:30:20.006114-0500 emacs[28189:1400131] fopen failed for data file: errno = 2 (No such file or directory) 2021-01-19 11:30:20.006128-0500 emacs[28189:1400131] Errors found! Invalidating cache... Process 28189 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 libsystem_kernel.dylib`read: -> 0x18cc708d0 <+8>: b.lo 0x18cc708f0 ; <+40> 0x18cc708d4 <+12>: pacibsp 0x18cc708d8 <+16>: stp x29, x30, [sp, #-0x10]! 0x18cc708dc <+20>: mov x29, sp Target 0: (emacs) stopped. (lldb) bt Process 28189 exited with status = 0 (0x00000000) Terminated due to signal 9 warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available. * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM * frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 frame #1: 0x00000001000de1c8 emacs`emacs_read [inlined] emacs_intr_read(fd=17, buf=0x000000016fdfbb3f, nbyte=<no summary available>, interruptible=<no summary available>) at sysdep.c:2486:16 [opt] frame #2: 0x00000001000de1b8 emacs`emacs_read(fd=<no summary available>, buf=<unavailable>, nbyte=<no summary available>) at sysdep.c:2500 [opt] and after compiling with -O0 -g3: ddavis@charm ~/software/repos/emacs (HEAD detached at 8f0ce42d3e) $ lldb src/emacs (lldb) target create "src/emacs" Current executable set to '/Users/ddavis/software/repos/emacs/src/emacs' (arm64). (lldb) run Process 60350 launched: '/Users/ddavis/software/repos/emacs/src/emacs' (arm64) Process 60350 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 libsystem_kernel.dylib`read: -> 0x18cc708d0 <+8>: b.lo 0x18cc708f0 ; <+40> 0x18cc708d4 <+12>: pacibsp 0x18cc708d8 <+16>: stp x29, x30, [sp, #-0x10]! 0x18cc708dc <+20>: mov x29, sp Target 0: (emacs) stopped. (lldb) thread list Process 60350 stopped * thread #1: tid = 0x1764c3, 0x000000018cc708d0 libsystem_kernel.dylib`read + 8, queue = 'com.apple.main-thread', stop reason = signal SIGTERM thread #4: tid = 0x1764f7, 0x000000018cc77e04 libsystem_kernel.dylib`poll + 8, name = 'gmain' thread #5: tid = 0x176508, 0x000000018cc7a0e8 libsystem_kernel.dylib`__select + 8 thread #6: tid = 0x176520, 0x000000018cc6fce8 libsystem_kernel.dylib`mach_msg_trap + 8, name = 'com.apple.NSEventThread' thread #36: tid = 0x178ca1, 0x000000018cc719c4 libsystem_kernel.dylib`__workq_kernreturn + 8 thread #38: tid = 0x1790f4, 0x000000018cc719c4 libsystem_kernel.dylib`__workq_kernreturn + 8 (lldb) thread backtrace all Process 60350 exited with status = 0 (0x00000000) Terminated due to signal 9 warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available. * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM * frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 frame #1: 0x0000000100170254 emacs`emacs_intr_read(fd=17, buf=<unavailable>, nbyte=<no summary available>, interruptible=<no summary available>) at sysdep.c:2486:16 thread #4, name = 'gmain' frame #0: 0xffffffffffffffff thread #5 frame #0: 0xffffffffffffffff thread #6, name = 'com.apple.NSEventThread' frame #0: 0xffffffffffffffff thread #36 frame #0: 0xffffffffffffffff thread #38 frame #0: 0xffffffffffffffff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 17:19 ` Doug Davis @ 2021-01-19 18:09 ` Philipp Stephani 2021-01-19 20:27 ` Simon Leinen 0 siblings, 1 reply; 9+ messages in thread From: Philipp Stephani @ 2021-01-19 18:09 UTC (permalink / raw) To: Doug Davis; +Cc: Eli Zaretskii, Emacs developers, herbert, Pankaj Jangid Am Di., 19. Jan. 2021 um 18:40 Uhr schrieb Doug Davis <ddavis@ddavis.io>: > > I've been able to reproduce the crash. > > Eli Zaretskii <eliz@gnu.org> writes: > > > Can you attach a debugger to Emacs when it freezes, and show the > > C-level backtrace? > > Here's my novice debugger attempt (apologies if it's not helpful); first > after compiling with -O3 -g3: > > ddavis@charm ~/software/repos/emacs (HEAD detached at 8f0ce42d3e) $ lldb src/emacs > (lldb) target create "src/emacs" > Current executable set to '/Users/ddavis/software/repos/emacs/src/emacs' (arm64). > (lldb) run > Process 28189 launched: '/Users/ddavis/software/repos/emacs/src/emacs' (arm64) > 2021-01-19 11:30:20.006114-0500 emacs[28189:1400131] fopen failed for data file: errno = 2 (No such file or directory) > 2021-01-19 11:30:20.006128-0500 emacs[28189:1400131] Errors found! Invalidating cache... > Process 28189 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM > frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 > libsystem_kernel.dylib`read: > -> 0x18cc708d0 <+8>: b.lo 0x18cc708f0 ; <+40> > 0x18cc708d4 <+12>: pacibsp > 0x18cc708d8 <+16>: stp x29, x30, [sp, #-0x10]! > 0x18cc708dc <+20>: mov x29, sp > Target 0: (emacs) stopped. > (lldb) bt > Process 28189 exited with status = 0 (0x00000000) Terminated due to signal 9 > warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available. > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM > * frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 > frame #1: 0x00000001000de1c8 emacs`emacs_read [inlined] emacs_intr_read(fd=17, buf=0x000000016fdfbb3f, nbyte=<no summary available>, interruptible=<no summary available>) at sysdep.c:2486:16 [opt] > frame #2: 0x00000001000de1b8 emacs`emacs_read(fd=<no summary available>, buf=<unavailable>, nbyte=<no summary available>) at sysdep.c:2500 [opt] > > and after compiling with -O0 -g3: > > ddavis@charm ~/software/repos/emacs (HEAD detached at 8f0ce42d3e) $ lldb src/emacs > (lldb) target create "src/emacs" > Current executable set to '/Users/ddavis/software/repos/emacs/src/emacs' (arm64). > (lldb) run > Process 60350 launched: '/Users/ddavis/software/repos/emacs/src/emacs' (arm64) > Process 60350 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM > frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 > libsystem_kernel.dylib`read: > -> 0x18cc708d0 <+8>: b.lo 0x18cc708f0 ; <+40> > 0x18cc708d4 <+12>: pacibsp > 0x18cc708d8 <+16>: stp x29, x30, [sp, #-0x10]! > 0x18cc708dc <+20>: mov x29, sp > Target 0: (emacs) stopped. > (lldb) thread list > Process 60350 stopped > * thread #1: tid = 0x1764c3, 0x000000018cc708d0 libsystem_kernel.dylib`read + 8, queue = 'com.apple.main-thread', stop reason = signal SIGTERM > thread #4: tid = 0x1764f7, 0x000000018cc77e04 libsystem_kernel.dylib`poll + 8, name = 'gmain' > thread #5: tid = 0x176508, 0x000000018cc7a0e8 libsystem_kernel.dylib`__select + 8 > thread #6: tid = 0x176520, 0x000000018cc6fce8 libsystem_kernel.dylib`mach_msg_trap + 8, name = 'com.apple.NSEventThread' > thread #36: tid = 0x178ca1, 0x000000018cc719c4 libsystem_kernel.dylib`__workq_kernreturn + 8 > thread #38: tid = 0x1790f4, 0x000000018cc719c4 libsystem_kernel.dylib`__workq_kernreturn + 8 > (lldb) thread backtrace all > Process 60350 exited with status = 0 (0x00000000) Terminated due to signal 9 > warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available. > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTERM > * frame #0: 0x000000018cc708d0 libsystem_kernel.dylib`read + 8 > frame #1: 0x0000000100170254 emacs`emacs_intr_read(fd=17, buf=<unavailable>, nbyte=<no summary available>, interruptible=<no summary available>) at sysdep.c:2486:16 This backtrace looks surprisingly short, and I'm wondering why the arguments got optimized out even with -O0? Any chance you could produce a longer backtrace? I'm also trying to reproduce this, but haven't had any luck so far. > thread #4, name = 'gmain' > frame #0: 0xffffffffffffffff > thread #5 > frame #0: 0xffffffffffffffff > thread #6, name = 'com.apple.NSEventThread' > frame #0: 0xffffffffffffffff > thread #36 > frame #0: 0xffffffffffffffff > thread #38 > frame #0: 0xffffffffffffffff > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 18:09 ` Philipp Stephani @ 2021-01-19 20:27 ` Simon Leinen 2021-01-19 20:41 ` Philipp Stephani 0 siblings, 1 reply; 9+ messages in thread From: Simon Leinen @ 2021-01-19 20:27 UTC (permalink / raw) To: Philipp Stephani Cc: Eli Zaretskii, Pankaj Jangid, Doug Davis, herbert, Emacs developers [-- Attachment #1: Type: text/plain, Size: 11048 bytes --] I have been experiencing the same issue for the past few days. Emacs compiled (to a nextstep application) from master on MacOS occasionally hangs while retrieving mail (headers) from an IMAP server in Gnus. When this happens, I can get out of the hang once by sending it a TERM signal (kill $(pgrep Emacs)). But if this happens a second time, this actually kills Emacs. Here's an all-threads backtrace after running it under the debugger, waiting for Emacs to hang, and then interrupting the process in the debugger: (lldb) thread list Process 68250 stopped * thread #1: tid = 0x1b50e0, 0x00007fff70d9681e libsystem_kernel.dylib`read + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP thread #4: tid = 0x1b51a3, 0x00007fff70d9c3d6 libsystem_kernel.dylib`poll + 10, name = 'gmain' thread #8: tid = 0x1b51b1, 0x00007fff70d9e0fe libsystem_kernel.dylib`__select + 10 thread #11: tid = 0x1b51c4, 0x00007fff70d95dfa libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread' thread #28: tid = 0x1b5a50, 0x00007fff70d974ce libsystem_kernel.dylib`__workq_kernreturn + 10 thread #33: tid = 0x1b5a6d, 0x00007fff70d974ce libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) thread backtrace all * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff70d9681e libsystem_kernel.dylib`read + 10 frame #1: 0x00000001000e1d5e Emacs`emacs_read [inlined] emacs_intr_read(fd=25, buf=0x00007ffeefbfd1bf, nbyte=1, interruptible=false) at sysdep.c:2486:16 [opt] frame #2: 0x00000001000e1d44 Emacs`emacs_read(fd=25, buf=0x00007ffeefbfd1bf, nbyte=1) at sysdep.c:2500 [opt] frame #3: 0x00000001001a0f66 Emacs`child_signal_read(fd=<unavailable>, data=<unavailable>) at process.c:7196:7 [opt] frame #4: 0x000000010019cd1e Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=<unavailable>, do_display=false, wait_for_cell=0x0000000000000000, wait_proc=<unavailable>, just_wait_proc=0) at process.c:5719:13 [opt] frame #5: 0x000000010019b5b9 Emacs`Faccept_process_output(process=0x0000000105ef1a95, seconds=0x000000010584b187, millisec=<unavailable>, just_this_one=<unavailable>) at process.c:4790:7 [opt] frame #6: 0x000000010014eea1 Emacs`funcall_subr(subr=0x0000000100271f28, numargs=2, args=<unavailable>) at eval.c:2990:19 [opt] frame #7: 0x000000010014e491 Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2909:11 [opt] frame #8: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x000000010ddb8cc4, vector=0x00000001064de805, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #9: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #10: 0x000000010014f28e Emacs`funcall_lambda(fun=0x00000001064de3d5, nargs=1, arg_vector=0x00007ffeefbfd8e0) at eval.c:3181 [opt] frame #11: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #12: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x0000000158641c54, vector=0x0000000107a8091d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #13: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #14: 0x000000010014f28e Emacs`funcall_lambda(fun=0x0000000107a80a55, nargs=1, arg_vector=0x00007ffeefbfdb80) at eval.c:3181 [opt] frame #15: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #16: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x0000000158641b64, vector=0x000000010342e7dd, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #17: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #18: 0x000000010014f28e Emacs`funcall_lambda(fun=0x0000000107a8012d, nargs=1, arg_vector=0x00007ffeefbfdd00) at eval.c:3181 [opt] frame #19: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #20: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x0000000158641aa4, vector=0x0000000107a8007d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #21: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #22: 0x000000010014f28e Emacs`funcall_lambda(fun=0x0000000107a80105, nargs=1, arg_vector=0x00007ffeefbfded0) at eval.c:3181 [opt] frame #23: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #24: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x000000015863f874, vector=0x0000000107a70e2d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #25: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #26: 0x000000010014f28e Emacs`funcall_lambda(fun=0x0000000107a70e7d, nargs=2, arg_vector=0x00007ffeefbfe070) at eval.c:3181 [opt] frame #27: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #28: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x0000000105219df4, vector=0x000000015903059d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #29: 0x000000010014f2ba Emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3031:10 [opt] frame #30: 0x000000010014f28e Emacs`funcall_lambda(fun=0x00000001067fb845, nargs=1, arg_vector=0x00007ffeefbfe7b0) at eval.c:3181 [opt] frame #31: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #32: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x0000000102f23484, vector=0x000000010380cf95, maxdepth=<unavailable>, args_template=<unavailable>, nargs=0, args=<unavailable>) at bytecode.c:632:12 [opt] frame #33: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #34: 0x0000000100147699 Emacs`Ffuncall_interactively(nargs=<unavailable>, args=<unavailable>) at callint.c:253:32 [opt] frame #35: 0x000000010014e491 Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2909:11 [opt] frame #36: 0x0000000100147b7d Emacs`Fcall_interactively(function=0x00000000072787f0, record_flag=0x0000000000000000, keys=0x00000001062b65c5) at callint.c:346:36 [opt] frame #37: 0x000000010014eed1 Emacs`funcall_subr(subr=0x000000010026e9e8, numargs=3, args=<unavailable>) at eval.c:2987:19 [opt] frame #38: 0x000000010014e491 Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2909:11 [opt] frame #39: 0x00000001001937b2 Emacs`exec_byte_code(bytestr=0x00000001042672bc, vector=0x0000000104266add, maxdepth=<unavailable>, args_template=<unavailable>, nargs=1, args=<unavailable>) at bytecode.c:632:12 [opt] frame #40: 0x000000010014e42f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt] frame #41: 0x000000010014eb0c Emacs`call1(fn=<unavailable>, arg1=<unavailable>) at eval.c:2769:10 [opt] frame #42: 0x00000001000c724e Emacs`command_loop_1 at keyboard.c:1466:13 [opt] frame #43: 0x000000010014c8a7 Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(Emacs`cmd_error at keyboard.c:922)) at eval.c:1441:25 [opt] frame #44: 0x00000001000d6e70 Emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt] frame #45: 0x000000010014c082 Emacs`internal_catch(tag=0x000000000000cae0, func=<unavailable>, arg=<unavailable>) at eval.c:1185:25 [opt] frame #46: 0x0000000100212885 Emacs`command_loop.cold.1 + 69 frame #47: 0x00000001000c60a3 Emacs`command_loop at keyboard.c:1070:5 [opt] frame #48: 0x00000001000c5fd3 Emacs`recursive_edit_1 at keyboard.c:720:9 [opt] frame #49: 0x00000001000c622b Emacs`Frecursive_edit at keyboard.c:789:3 [opt] frame #50: 0x00000001000c4dbc Emacs`main(argc=<unavailable>, argv=0x00007ffeefbff358) at emacs.c:2049:3 [opt] frame #51: 0x00007fff70c54cc9 libdyld.dylib`start + 1 frame #52: 0x00007fff70c54cc9 libdyld.dylib`start + 1 thread #4, name = 'gmain' frame #0: 0x00007fff70d9c3d6 libsystem_kernel.dylib`poll + 10 frame #1: 0x0000000102011fc1 libglib-2.0.0.dylib`g_main_context_iterate + 433 frame #2: 0x00000001020120c6 libglib-2.0.0.dylib`g_main_context_iteration + 102 frame #3: 0x00000001020140e1 libglib-2.0.0.dylib`glib_worker_main + 33 frame #4: 0x000000010203ec32 libglib-2.0.0.dylib`g_thread_proxy + 66 frame #5: 0x00007fff70e59109 libsystem_pthread.dylib`_pthread_start + 148 frame #6: 0x00007fff70e54b8b libsystem_pthread.dylib`thread_start + 15 thread #8 frame #0: 0x00007fff70d9e0fe libsystem_kernel.dylib`__select + 10 frame #1: 0x00000001001da3ef Emacs`-[EmacsApp fd_handler:](self=<unavailable>, _cmd=<unavailable>, unused=<unavailable>) at nsterm.m:6156:20 [opt] frame #2: 0x00007fff392367b2 Foundation`__NSThread__start__ + 1064 frame #3: 0x00007fff70e59109 libsystem_pthread.dylib`_pthread_start + 148 frame #4: 0x00007fff70e54b8b libsystem_pthread.dylib`thread_start + 15 thread #11, name = 'com.apple.NSEventThread' frame #0: 0x00007fff70d95dfa libsystem_kernel.dylib`mach_msg_trap + 10 frame #1: 0x00007fff70d96170 libsystem_kernel.dylib`mach_msg + 60 frame #2: 0x00007fff36ba4ef5 CoreFoundation`__CFRunLoopServiceMachPort + 247 frame #3: 0x00007fff36ba39c2 CoreFoundation`__CFRunLoopRun + 1319 frame #4: 0x00007fff36ba2e3e CoreFoundation`CFRunLoopRunSpecific + 462 frame #5: 0x00007fff33fb6954 AppKit`_NSEventThread + 132 frame #6: 0x00007fff70e59109 libsystem_pthread.dylib`_pthread_start + 148 frame #7: 0x00007fff70e54b8b libsystem_pthread.dylib`thread_start + 15 thread #28 frame #0: 0x00007fff70e54b68 libsystem_pthread.dylib`start_wqthread thread #33 frame #0: 0x00007fff70d974ce libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x00007fff70e55aa1 libsystem_pthread.dylib`_pthread_wqthread + 390 frame #2: 0x00007fff70e54b77 libsystem_pthread.dylib`start_wqthread + 15 (lldb) emacs-repository-version is 8f4b3b812aab62a5a205bc2f8690c3b4c460ba09 -- Simon. [-- Attachment #2: Type: text/html, Size: 12095 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 20:27 ` Simon Leinen @ 2021-01-19 20:41 ` Philipp Stephani 2021-01-20 8:59 ` Pankaj Jangid 0 siblings, 1 reply; 9+ messages in thread From: Philipp Stephani @ 2021-01-19 20:41 UTC (permalink / raw) To: Simon Leinen Cc: Eli Zaretskii, Pankaj Jangid, Doug Davis, herbert, Emacs developers Am Di., 19. Jan. 2021 um 21:27 Uhr schrieb Simon Leinen <simon.leinen@gmail.com>: > > I have been experiencing the same issue for the past few days. Emacs compiled (to a nextstep application) from master on MacOS occasionally hangs while retrieving mail (headers) from an IMAP server in Gnus. When this happens, I can get out of the hang once by sending it a TERM signal (kill $(pgrep Emacs)). But if this happens a second time, this actually kills Emacs. Here's an all-threads backtrace after running it under the debugger, waiting for Emacs to hang, and then interrupting the process in the debugger: > Thanks, that backtrace is very helpful. I hope I fixed this issue with commit 8ed97a8d543b9596166c670212265dabc44aa3d5; however, it would still be great if someone could reproduce it systematically so I can add a regression test. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [emacs-master] Frequent freezes on macOS 2021-01-19 20:41 ` Philipp Stephani @ 2021-01-20 8:59 ` Pankaj Jangid 0 siblings, 0 replies; 9+ messages in thread From: Pankaj Jangid @ 2021-01-20 8:59 UTC (permalink / raw) To: Philipp Stephani Cc: Simon Leinen, Eli Zaretskii, Doug Davis, herbert, Emacs developers Philipp Stephani <p.stephani2@gmail.com> writes: > Thanks, that backtrace is very helpful. I hope I fixed this issue with > commit 8ed97a8d543b9596166c670212265dabc44aa3d5; however, it would > still be great if someone could reproduce it systematically so I can > add a regression test. Working fine since morning. Thanks a lot for the fix. Thanks everyone. I also got myself started into using a debugger. :-) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-01-20 8:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-19 6:44 [emacs-master] Frequent freezes on macOS Pankaj Jangid 2021-01-19 9:28 ` Herbert J. Skuhra 2021-01-19 15:31 ` Pankaj Jangid 2021-01-19 15:39 ` Eli Zaretskii 2021-01-19 17:19 ` Doug Davis 2021-01-19 18:09 ` Philipp Stephani 2021-01-19 20:27 ` Simon Leinen 2021-01-19 20:41 ` Philipp Stephani 2021-01-20 8:59 ` Pankaj Jangid
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).