unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [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).