I just did one more quick test. I renamed .emacs.d/elpa where I only have the newer version tramp to .emacs.d/elpa-bak. That seems to fix the problem. Mani On Fri, Aug 27, 2021 at 1:37 PM Mani Kancherla wrote: > Hi, > > I verified that "emacs -Q" has no issues. I can reproduce the issue > consistently without "-Q". Any information I can collect that will help > debug the issue? > > Thanks, > Mani > > On Thu, Aug 26, 2021 at 11:51 PM Michael Albinus > wrote: > >> Eli Zaretskii writes: >> >> Hi, >> >> > This backtrace is very strange. This part: >> > >> > frame #30: 0x00000001001bde9b emacs`ns_run_loop_break at >> nsterm.m:4760:5 [opt] >> > frame #31: 0x00000001001a9e6e >> emacs`sys_cond_broadcast(cond=) at systhread.c:183:3 [opt] >> > frame #32: 0x00000001001a9c59 >> emacs`lisp_mutex_unlock(mutex=) at thread.c:230:3 [opt] >> > frame #33: 0x00000001001a8af6 >> emacs`mutex_unlock_callback(arg=) at thread.c:339:7 [opt] >> > frame #34: 0x0000000100120264 >> emacs`flush_stack_call_func(func=, arg=) at >> alloc.c:4951:3 [opt] >> > frame #35: 0x00000001001a8ac5 >> emacs`Fmutex_unlock(mutex=0x0000000101c46065) at thread.c:355:3 [opt] >> > frame #36: 0x0000000100146bdb >> emacs`funcall_subr(subr=0x00000001002582f8, numargs=1, args=) >> at eval.c:2868:19 [opt] >> > frame #37: 0x000000010014625c emacs`Ffuncall(nargs=, >> args=) at eval.c:2795:11 [opt] >> > >> > says that funcall_subr calls Fmutex_unlock from line 2868 of eval.c, >> > but that is false. It could be that the debugger is not presenting >> > the full backtrace, because this is an optimized build, and some >> > backtrace frames are missing due to inlining. >> >> Does the problem also happen when calling "emacs -Q"? The GNU ELPA Tramp >> package contains some thread code, leftover from my attempts to add such >> support to Tramp (and which I hope to reanimate). It should be >> deactivated by default. >> >> The builtin version of Tramp does not contain this code. >> >> Best regards, Michael. >> >