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.