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 <michael.albinus@gmx.de>
wrote:

> Eli Zaretskii <eliz@gnu.org> 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=<unavailable>) at systhread.c:183:3 [opt]
> >     frame #32: 0x00000001001a9c59
> emacs`lisp_mutex_unlock(mutex=<unavailable>) at thread.c:230:3 [opt]
> >     frame #33: 0x00000001001a8af6
> emacs`mutex_unlock_callback(arg=<unavailable>) at thread.c:339:7 [opt]
> >     frame #34: 0x0000000100120264
> emacs`flush_stack_call_func(func=<unavailable>, arg=<unavailable>) 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=<unavailable>)
> at eval.c:2868:19 [opt]
> >     frame #37: 0x000000010014625c emacs`Ffuncall(nargs=<unavailable>,
> args=<unavailable>) 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.
>