bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

This bug report is against the feature/tramp-thread-safe branch,
162353c45c.

Continuous typing during an asynchronous find-file will result in
garbled input because the cursor periodically jumps backwards.

To reproduce, with emacs -Q, *scratch* as the current buffer,
and a remote machine with the Emacs source tree:

C-x & C-x C-f scp:server:src/emacs/lisp/emacs-lisp/b*.el RET

Then type "The rain in Spain falls mainly on the plain." or other
sentence of your choice, over and over.  Stop when the message about
checking vc-registered appears in the echo area.

Result: There will be a pause before the first typed text appears, then
Emacs will start showing the typed text normally, except periodically
the cursor will jump backwards so text will be inserted in the wrong
place.

After the first vc-registered message, Emacs will stop responding to
input until after a buffer for one of the opened files is displayed.

I'm running Emacs on a laptop which is using my cell phone's mobile
hotspot to connect to a machine on my home network, meaning there is
significant latency.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.28)
 of 2018-08-21 built on sockeye
Repository revision: 162353c45cf7ae8c5626a5062c247a793e30e7d0
System Description: NixOS 18.03.git.bd06547 (Impala)

Recent messages:

Tramp: Checking ‘vc-registered’ for /scp:chinook:/home/gem/src/emacs/master/lisp/emacs-lisp/bytecomp.el...done

Tramp: Checking ‘vc-registered’ for /scp:chinook:/home/gem/src/emacs/master/lisp/emacs-lisp/backquote.el...done

Tramp: Checking ‘vc-registered’ for /scp:chinook:/home/gem/src/emacs/master/lisp/emacs-lisp/byte-run.el...done

Tramp: Checking ‘vc-registered’ for /scp:chinook:/home/gem/src/emacs/master/lisp/emacs-lisp/benchmark.el...done
Undo!
C-x M-x is undefined
Quit
Configured using:
 'configure --prefix=/home/gem/src/emacs/tramp/bin --with-modules
 --with-x-toolkit=gtk3 --with-xft --config-cache'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
MODULES THREADS LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils vc-git diff-mode easymenu easy-mmode
files-x tramp-sh tramp-cache tramp trampver tramp-compat tramp-loaddefs
ucs-normalize shell pcomplete comint ansi-color ring parse-time
format-spec advice auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib term/xterm xterm time-date
elec-pair mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 231578 10507)
 (symbols 48 22696 1)
 (strings 32 37905 1930)
 (string-bytes 1 1127065)
 (vectors 16 38578)
 (vector-slots 8 747585 13268)
 (floats 8 72 538)
 (intervals 56 347 0)
 (buffers 992 24))

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Date: Sun, 26 Aug 2018 10:39:55 -0700
> 
> Then type "The rain in Spain falls mainly on the plain." or other
> sentence of your choice, over and over.  Stop when the message about
> checking vc-registered appears in the echo area.
> 
> Result: There will be a pause before the first typed text appears, then
> Emacs will start showing the typed text normally, except periodically
> the cursor will jump backwards so text will be inserted in the wrong
> place.

I guess some code in the background thread calls a yielding function
inside save-excursion or something?  I'd try running with a breakpoint
in set_point_both and temp_set_point_both, with commands that show the
backtrace and immediately continue the program.  Then you might see
the culprit.

Or maybe Michael will know where that happens given the description.

> After the first vc-registered message, Emacs will stop responding to
> input until after a buffer for one of the opened files is displayed.

That is not necessarily a bug: if some thread performs some prolonged
calculation, no other thread will be able to run, and no input will be
accepted.  Just like with a single thread.

Thanks.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

> I guess some code in the background thread calls a yielding function
> inside save-excursion or something?  I'd try running with a breakpoint
> in set_point_both and temp_set_point_both, with commands that show the
> backtrace and immediately continue the program.  Then you might see
> the culprit.

Here is an excerpt from my gdb output from following your instructions.
(I made the breakpoints conditional on the buffer being *scratch*.)  It
looks like your guess is correct, since there is a save-excursion in
tramp-sh-handle-file-attributes wrapping code that executes commands
on the remote machine.


Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=195, 
    bytepos=195) at intervals.c:1826
1826	{
"electric-indent-post-self-insert-function" (0xf9420)
"self-insert-command" (0xf9620)
"funcall-interactively" (0xf9618)
"call-interactively" (0xf98f0)
"command-execute" (0xf9c08)
[Switching to Thread 0x7f1cad3e1700 (LWP 9151)]

Thread 5 "emacs" hit Breakpoint 4, set_point_both (charpos=146, bytepos=146)
    at intervals.c:1826
1826	{
"tramp-sh-handle-file-attributes" (0xad3db0b8)
"apply" (0xad3db1f0)
"tramp-sh-file-name-handler" (0xad3db498)
"apply" (0xad3db648)
"tramp-file-name-handler" (0xad3dc688)
"file-attributes" (0xad3dc7e0)
"tramp-check-cached-permissions" (0xad3dcbb0)
"tramp-sh-handle-file-readable-p" (0xad3dcff8)
"apply" (0xad3dcff0)
"tramp-sh-file-name-handler" (0xad3dd420)
"apply" (0xad3dd418)
"tramp-file-name-handler" (0xad3de458)
"file-readable-p" (0xad3de578)
"tramp-handle-file-accessible-directory-p" (0xad3de8f8)
"apply" (0xad3de8f0)
"tramp-sh-file-name-handler" (0xad3ded20)
"apply" (0xad3ded18)
"tramp-file-name-handler" (0xad3dfd58)
"file-accessible-directory-p" (0xad3dfec8)
"file-expand-wildcards" (0xad3e0218)
"find-file-noselect" (0xad3e07e0)
0x4867b10 PVEC_COMPILED

Thread 5 "emacs" hit Breakpoint 5, temp_set_point_both (
    buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=146, 
    bytepos=bytepos@entry=146) at intervals.c:1729
1729	{
"tramp-sh-handle-file-attributes" (0xad3db0b8)
"apply" (0xad3db1f0)
"tramp-sh-file-name-handler" (0xad3db498)
"apply" (0xad3db648)
"tramp-file-name-handler" (0xad3dc688)
"file-attributes" (0xad3dc7e0)
"tramp-check-cached-permissions" (0xad3dcbb0)
"tramp-sh-handle-file-readable-p" (0xad3dcff8)
"apply" (0xad3dcff0)
"tramp-sh-file-name-handler" (0xad3dd420)
"apply" (0xad3dd418)
"tramp-file-name-handler" (0xad3de458)
"file-readable-p" (0xad3de578)
"tramp-handle-file-accessible-directory-p" (0xad3de8f8)
"apply" (0xad3de8f0)
"tramp-sh-file-name-handler" (0xad3ded20)
"apply" (0xad3ded18)
"tramp-file-name-handler" (0xad3dfd58)
"file-accessible-directory-p" (0xad3dfec8)
"file-expand-wildcards" (0xad3e0218)
"find-file-noselect" (0xad3e07e0)
0x4867b10 PVEC_COMPILED
[Switching to Thread 0x7f1cc590db40 (LWP 8465)]

Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=147, 
    bytepos=147) at intervals.c:1826
1826	{
"electric-indent-post-self-insert-function" (0xf9420)
"self-insert-command" (0xf9620)
"funcall-interactively" (0xf9618)
"call-interactively" (0xf98f0)
"command-execute" (0xf9c08)

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Tue, 28 Aug 2018 12:48:28 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I guess some code in the background thread calls a yielding function
> > inside save-excursion or something?  I'd try running with a breakpoint
> > in set_point_both and temp_set_point_both, with commands that show the
> > backtrace and immediately continue the program.  Then you might see
> > the culprit.
> 
> Here is an excerpt from my gdb output from following your instructions.
> (I made the breakpoints conditional on the buffer being *scratch*.)

Thanks.

> It looks like your guess is correct, since there is a save-excursion
> in tramp-sh-handle-file-attributes wrapping code that executes
> commands on the remote machine.

Hmm... does that mean tramp-sh-handle-file-attributes runs with
*scratch* is its current buffer?  It was *scratch* that you were
typing into when this point jumps happened, right?  It's strange that
Tramp uses the current buffer for its processing, but Michael should
know.

If tramp-sh-handle-file-attributes is not using *scratch*, then we'll
need to find some other code in the functions run in backtrace that
does.

> Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=195, 
>     bytepos=195) at intervals.c:1826
> 1826	{
> "electric-indent-post-self-insert-function" (0xf9420)
> "self-insert-command" (0xf9620)
> "funcall-interactively" (0xf9618)
> "call-interactively" (0xf98f0)
> "command-execute" (0xf9c08)

Wait a minute, why does self-insert-command run in a non-main thread?
Could it be that somehow a non-main thread started receiving and
interpreting your keyboard input?  (The "find-file /scp:" thread is
not the main thread, right?)

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

> Hmm... does that mean tramp-sh-handle-file-attributes runs with
> *scratch* is its current buffer?  It was *scratch* that you were
> typing into when this point jumps happened, right?  It's strange that
> Tramp uses the current buffer for its processing, but Michael should
> know.

Yes, I was typing into *scratch*.  I'm a gdb newbie, so here's what I
did:

1. From a shell, cd to src, run ./emacs -Q
2. M-x global-font-lock-mode RET
3. From another shell, cd to src, determine PID of Emacs and then run
   gdb -p PID
4. Enter following commands to gdb:

source .gdbinit
set logging on
set height 0
p current_thread->m_current_buffer
break Fmake_thread
cont

5. Return to Emacs and enter:
   C-x C-f C-a C-k /scp:server:src/emacs/lisp/emacs-lisp/b*.el RET
6. In gdb, enter the following:

clear
break set_point_both if current_thread->m_current_buffer == $1
commands
xbacktrace
cont
end
break temp_set_point_both if buffer == $1
commands
xbacktrace
cont
end
cont

8. Return to Emacs and type until the cursor makes a backward jump.
9. C-x C-c

> Wait a minute, why does self-insert-command run in a non-main thread?
> Could it be that somehow a non-main thread started receiving and
> interpreting your keyboard input?  (The "find-file /scp:" thread is
> not the main thread, right?)

It looks to me like Thread 1 is the main thread, and the thread names
printed by gdb don't match what Emacs thinks they are.  Thread 1 starts
out as "emacs" but its name changes after I continue from the
Fmake_thread breakpoint:


Thread 1 "emacs" hit Breakpoint 3, Fmake_thread (function=XIL(0x4867b15), 
    name=XIL(0x45b85a4)) at thread.c:768
768	{
Deleted breakpoint 3 
Breakpoint 4 at 0x635530: file intervals.c, line 1826.
Type commands for breakpoint(s) 4, one per line.
End with a line saying just "end".
Breakpoint 5 at 0x635360: file intervals.c, line 1729.
Type commands for breakpoint(s) 5, one per line.
End with a line saying just "end".
Continuing.
[New Thread 0x7f1cad3e1700 (LWP 9151)]

Thread 1 "find-file /scp:" hit Breakpoint 5, temp_set_point_both (
    buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=146, 
    bytepos=bytepos@entry=146) at intervals.c:1729
1729	{
"redisplay_internal (C function)" (0x0)


And then later in gdb.txt this thread shows up:


Thread 6 "emacs" hit Breakpoint 5, temp_set_point_both (
    buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=151, 
    bytepos=bytepos@entry=151) at intervals.c:1729
1729	{
"redisplay_internal (C function)" (0x0)
"message" (0xaca48708)
"apply" (0xaca48700)
"tramp-sh-handle-file-local-copy" (0xaca492d8)
"apply" (0xaca492d0)
"tramp-sh-file-name-handler" (0xaca49700)
"apply" (0xaca496f8)
"tramp-file-name-handler" (0xaca4a750)
"file-local-copy" (0xaca4aa70)
"tramp-handle-insert-file-contents" (0xaca4b278)
"apply" (0xaca4b3c0)
"tramp-sh-file-name-handler" (0xaca4b668)
"apply" (0xaca4b838)
"tramp-file-name-handler" (0xaca4c878)
"insert-file-contents" (0xaca50eb8)
"find-file-noselect-1" (0xaca51270)
"find-file-noselect" (0xaca51810)
0x4860a20 PVEC_COMPILED

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Wed, 29 Aug 2018 10:55:35 -0700
> 
> I'm a gdb newbie

You are doing fine, don't worry.

> It looks to me like Thread 1 is the main thread, and the thread names
> printed by gdb don't match what Emacs thinks they are.  Thread 1 starts
> out as "emacs" but its name changes after I continue from the
> Fmake_thread breakpoint:
> 
> 
> Thread 1 "emacs" hit Breakpoint 3, Fmake_thread (function=XIL(0x4867b15), 
>     name=XIL(0x45b85a4)) at thread.c:768
> 768	{
> Deleted breakpoint 3 
> Breakpoint 4 at 0x635530: file intervals.c, line 1826.
> Type commands for breakpoint(s) 4, one per line.
> End with a line saying just "end".
> Breakpoint 5 at 0x635360: file intervals.c, line 1729.
> Type commands for breakpoint(s) 5, one per line.
> End with a line saying just "end".
> Continuing.
> [New Thread 0x7f1cad3e1700 (LWP 9151)]
> 
> Thread 1 "find-file /scp:" hit Breakpoint 5, temp_set_point_both (
>     buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=146, 
>     bytepos=bytepos@entry=146) at intervals.c:1729
> 1729	{
> "redisplay_internal (C function)" (0x0)
> 
> 
> And then later in gdb.txt this thread shows up:
> 
> 
> Thread 6 "emacs" hit Breakpoint 5, temp_set_point_both (
>     buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=151, 
>     bytepos=bytepos@entry=151) at intervals.c:1729

So given this confusion over which thread is what, I think we need to
see the C-level backtrace of all the Lisp threads, to see which one(s)
of them really called temp_set_point_both.

Thanks.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

> So given this confusion over which thread is what, I think we need to
> see the C-level backtrace of all the Lisp threads, to see which one(s)
> of them really called temp_set_point_both.

Printing the C-level backtraces on every breakpoint makes Emacs under
gdb too slow to let me reproduce the bug, so I came up with this
compromise:

break set_point_both if current_thread->m_current_buffer == $1
commands
p current_thread
xbacktrace
if current_thread != &main_thread
  thread apply 1 5-15 backtrace
end
cont
end
break temp_set_point_both if buffer == $1
commands
p current_thread
xbacktrace
if current_thread != &main_thread
  thread apply 1 5-15 backtrace
end
cont
end

I also commented out hookpost-backtrace in .gdbinit to make the
'thread apply' work.

Here's an excerpt from the log of the resulting gdb session, showing the
set_point_both and temp_set_point_both calls that move point backwards,
with the C-level backtraces of the Lisp threads:


Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=152,
    bytepos=152) at intervals.c:1826
1826	{
$37 = (struct thread_state *) 0xd45600 <main_thread>
"electric-indent-post-self-insert-function" (0xe407de80)
"self-insert-command" (0xe407e080)
"funcall-interactively" (0xe407e078)
"call-interactively" (0xe407e350)
"command-execute" (0xe407e668)
[Switching to Thread 0x7f8722610700 (LWP 27981)]

Thread 5 "emacs" hit Breakpoint 4, set_point_both (charpos=146, bytepos=146)
    at intervals.c:1826
1826	{
$38 = (struct thread_state *) 0x3fd5080
"tramp-sh-handle-file-attributes" (0x2260a0b8)
"apply" (0x2260a1f0)
"tramp-sh-file-name-handler" (0x2260a498)
"apply" (0x2260a648)
"tramp-file-name-handler" (0x2260b688)
"file-attributes" (0x2260b7e0)
"tramp-check-cached-permissions" (0x2260bbb0)
"tramp-sh-handle-file-readable-p" (0x2260bff8)
"apply" (0x2260bff0)
"tramp-sh-file-name-handler" (0x2260c420)
"apply" (0x2260c418)
"tramp-file-name-handler" (0x2260d458)
"file-readable-p" (0x2260d578)
"tramp-handle-file-accessible-directory-p" (0x2260d8f8)
"apply" (0x2260d8f0)
"tramp-sh-file-name-handler" (0x2260dd20)
"apply" (0x2260dd18)
"tramp-file-name-handler" (0x2260ed58)
"file-accessible-directory-p" (0x2260eec8)
"file-expand-wildcards" (0x2260f218)
"find-file-noselect" (0x2260f7e0)
0x3fd4350 PVEC_COMPILED

Thread 1 (Thread 0x7f873eb61b40 (LWP 27888)):
#0  0x00007f87384808cc in __lll_lock_wait () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00007f8738479a45 in pthread_mutex_lock () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#2  0x0000000000648df9 in sys_mutex_lock (mutex=mutex@entry=0xd455c0 <global_lock>) at systhread.c:137
#3  0x0000000000647582 in acquire_global_lock (self=0xd45600 <main_thread>) at thread.c:100
#4  really_call_select (arg=arg@entry=0x7ffce407d420) at thread.c:582
#5  0x00000000005aa698 in flush_stack_call_func (func=func@entry=0x6474f0 <really_call_select>, arg=arg@entry=0x7ffce407d420) at alloc.c:5103
#6  0x00000000006489f9 in thread_select (func=<optimized out>, max_fds=max_fds@entry=11, rfds=rfds@entry=0x7ffce407d500, wfds=wfds@entry=0x7ffce407d580, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffce407db60, sigmask=0x0) at thread.c:602
#7  0x000000000066ad16 in xg_select (fds_lim=11, rfds=rfds@entry=0x7ffce407dc60, wfds=wfds@entry=0x7ffce407dce0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffce407db60, sigmask=sigmask@entry=0x0) at xgselect.c:117
#8  0x0000000000622b61 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=..., wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5384
#9  0x000000000042931b in sit_for (timeout=..., reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5801
#10 0x000000000054c241 in read_char (commandflag=commandflag@entry=1, map=..., map@entry=XIL(0x413a593), prev_event=..., used_mouse_menu=used_mouse_menu@entry=0x7ffce407e5bb, end_time=end_time@entry=0x0) at keyboard.c:2688
#11 0x000000000054de99 in read_key_sequence (keybuf=keybuf@entry=0x7ffce407e700, prompt=..., prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:9108
#12 0x000000000054fc0e in command_loop_1 () at keyboard.c:1338
#13 0x00000000005cc4df in internal_condition_case (bfun=bfun@entry=0x54f9b0 <command_loop_1>, handlers=..., handlers@entry=XIL(0x5340), hfun=hfun@entry=0x542070 <cmd_error>) at eval.c:1349
#14 0x000000000053de38 in command_loop_2 (ignore=..., ignore@entry=XIL(0)) at keyboard.c:1079
#15 0x00000000005cc403 in internal_catch (tag=..., func=func@entry=0x53de10 <command_loop_2>, arg=..., arg@entry=XIL(0)) at eval.c:1114
#16 0x000000000053e06b in command_loop () at keyboard.c:1058
#17 0x0000000000541b74 in recursive_edit_1 () at keyboard.c:703
#18 0x0000000000541f3e in Frecursive_edit () at keyboard.c:774
#19 0x000000000041bfb2 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1756

Thread 5 (Thread 0x7f8722610700 (LWP 27981)):
#0  set_point_both (charpos=146, bytepos=146) at intervals.c:1826
#1  0x0000000000635f08 in set_point_from_marker (marker=..., marker@entry=XIL(0x3e59fc5)) at intervals.c:1771
#2  0x00000000005bbf32 in Fgoto_char (position=..., position@entry=XIL(0x3e59fc5)) at editfns.c:423
#3  0x00000000005c6920 in save_excursion_restore (marker=XIL(0x3e59fc5), window=...) at editfns.c:1023
#4  0x00000000005cce89 in unbind_to (count=<optimized out>, value=..., value@entry=XIL(0)) at eval.c:3593
#5  0x000000000061510f in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260a0b8) at bytecode.c:652
#6  0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f8722609d30), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260a0b8) at eval.c:3023
#7  0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=0x7f872260a0b0) at eval.c:2836
#8  0x00000000005cd755 in Fapply (nargs=2, args=<optimized out>) at eval.c:2442
#9  0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260a1e8) at eval.c:2822
#10 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7f872260a498) at bytecode.c:632
#11 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260a218), nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7f872260a498) at eval.c:3023
#12 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=4, args=0x7f872260a490) at eval.c:2836
#13 0x00000000005cd755 in Fapply (nargs=3, args=<optimized out>) at eval.c:2442
#14 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260a640) at eval.c:2822
#15 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7f872260b688) at bytecode.c:632
#16 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260a6b8), nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7f872260b688) at eval.c:3023
#17 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7f872260b680) at eval.c:2836
#18 0x00000000005d1864 in call3 (fn=..., arg1=..., arg2=..., arg3=...) at eval.c:2689
#19 0x00000000005cf2f3 in funcall_subr (subr=0x900720 <Sfile_attributes>, numargs=numargs@entry=2, args=args@entry=0x7f872260b7e0) at eval.c:2899
#20 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260b7d8) at eval.c:2822
#21 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260bbb0) at bytecode.c:632
#22 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260b818), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260bbb0) at eval.c:3023
#23 0x00000000005cd41d in Ffuncall (nargs=3, args=args@entry=0x7f872260bba8) at eval.c:2836
#24 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7f872260bff8) at bytecode.c:632
#25 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260bbd0), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7f872260bff8) at eval.c:3023
#26 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7f872260bff0) at eval.c:2836
#27 0x00000000005cd809 in Fapply (nargs=2, args=0x7f872260bff0) at eval.c:2399
#28 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260bfe8) at eval.c:2822
#29 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260c420) at bytecode.c:632
#30 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260c018), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260c420) at eval.c:3023
#31 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260c418) at eval.c:2836
#32 0x00000000005cd809 in Fapply (nargs=3, args=0x7f872260c418) at eval.c:2399
#33 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260c410) at eval.c:2822
#34 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260d458) at bytecode.c:632
#35 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260c488), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260d458) at eval.c:3023
#36 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260d450) at eval.c:2836
#37 0x00000000005cd5cf in call2 (fn=..., arg1=..., arg2=...) at eval.c:2681
#38 0x00000000005cf2fe in funcall_subr (subr=0x9000a0 <Sfile_readable_p>, numargs=numargs@entry=1, args=args@entry=0x7f872260d578) at eval.c:2897
#39 0x00000000005cd4af in Ffuncall (nargs=2, args=args@entry=0x7f872260d570) at eval.c:2822
#40 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7f872260d8f8) at bytecode.c:632
#41 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260d580), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7f872260d8f8) at eval.c:3023
#42 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7f872260d8f0) at eval.c:2836
#43 0x00000000005cd809 in Fapply (nargs=2, args=0x7f872260d8f0) at eval.c:2399
#44 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260d8e8) at eval.c:2822
#45 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260dd20) at bytecode.c:632
#46 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260d918), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260dd20) at eval.c:3023
#47 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260dd18) at eval.c:2836
#48 0x00000000005cd809 in Fapply (nargs=3, args=0x7f872260dd18) at eval.c:2399
#49 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260dd10) at eval.c:2822
#50 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260ed58) at bytecode.c:632
#51 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260dd88), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260ed58) at eval.c:3023
#52 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260ed50) at eval.c:2836
#53 0x00000000005cd5cf in call2 (fn=..., arg1=..., arg1@entry=XIL(0x5940), arg2=..., arg2@entry=XIL(0x7f8718024484)) at eval.c:2681
#54 0x0000000000582b87 in Ffile_accessible_directory_p (filename=...) at fileio.c:2825
#55 0x00000000005cf2fe in funcall_subr (subr=0x8fff60 <Sfile_accessible_directory_p>, numargs=numargs@entry=1, args=args@entry=0x7f872260eec8) at eval.c:2897
#56 0x00000000005cd4af in Ffuncall (nargs=2, args=args@entry=0x7f872260eec0) at eval.c:2822
#57 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260f218) at bytecode.c:632
#58 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260ef08), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260f218) at eval.c:3023
#59 0x00000000005cd41d in Ffuncall (nargs=3, args=args@entry=0x7f872260f210) at eval.c:2836
#60 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=5, args=<optimized out>, args@entry=0x7f872260f7e0) at bytecode.c:632
#61 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260f278), nargs=nargs@entry=5, arg_vector=arg_vector@entry=0x7f872260f7e0) at eval.c:3023
#62 0x00000000005cd41d in Ffuncall (nargs=6, args=args@entry=0x7f872260f7d8) at eval.c:2836
#63 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=0, args=<optimized out>, args@entry=0x3fd50a8) at bytecode.c:632
#64 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260f808), nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x3fd50a8) at eval.c:3023
#65 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x3fd50a0) at eval.c:2836
#66 0x00000000006473db in invoke_thread_function () at thread.c:684
#67 0x00000000005cc4df in internal_condition_case (bfun=bfun@entry=0x6473a0 <invoke_thread_function>, handlers=..., handlers@entry=XIL(0xc330), hfun=hfun@entry=0x6472c0 <record_thread_error>) at eval.c:1349
#68 0x0000000000647e01 in run_thread (state=0x3fd5080) at thread.c:723
#69 0x00007f87384772a7 in start_thread () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#70 0x00007f8737b1457f in clone () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libc.so.6
warning: Unknown thread 6
warning: Unknown thread 7
warning: Unknown thread 8
warning: Unknown thread 9
warning: Unknown thread 10
warning: Unknown thread 11
warning: Unknown thread 12
warning: Unknown thread 13
warning: Unknown thread 14
warning: Unknown thread 15

Thread 5 "emacs" hit Breakpoint 5, temp_set_point_both (
    buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=146,
    bytepos=bytepos@entry=146) at intervals.c:1729
1729	{
$39 = (struct thread_state *) 0x3fd5080
"tramp-sh-handle-file-attributes" (0x2260a0b8)
"apply" (0x2260a1f0)
"tramp-sh-file-name-handler" (0x2260a498)
"apply" (0x2260a648)
"tramp-file-name-handler" (0x2260b688)
"file-attributes" (0x2260b7e0)
"tramp-check-cached-permissions" (0x2260bbb0)
"tramp-sh-handle-file-readable-p" (0x2260bff8)
"apply" (0x2260bff0)
"tramp-sh-file-name-handler" (0x2260c420)
"apply" (0x2260c418)
"tramp-file-name-handler" (0x2260d458)
"file-readable-p" (0x2260d578)
"tramp-handle-file-accessible-directory-p" (0x2260d8f8)
"apply" (0x2260d8f0)
"tramp-sh-file-name-handler" (0x2260dd20)
"apply" (0x2260dd18)
"tramp-file-name-handler" (0x2260ed58)
"file-accessible-directory-p" (0x2260eec8)
"file-expand-wildcards" (0x2260f218)
"find-file-noselect" (0x2260f7e0)
0x3fd4350 PVEC_COMPILED

Thread 1 (Thread 0x7f873eb61b40 (LWP 27888)):
#0  0x00007f87384808cc in __lll_lock_wait () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00007f8738479a45 in pthread_mutex_lock () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#2  0x0000000000648df9 in sys_mutex_lock (mutex=mutex@entry=0xd455c0 <global_lock>) at systhread.c:137
#3  0x0000000000647582 in acquire_global_lock (self=0xd45600 <main_thread>) at thread.c:100
#4  really_call_select (arg=arg@entry=0x7ffce407d420) at thread.c:582
#5  0x00000000005aa698 in flush_stack_call_func (func=func@entry=0x6474f0 <really_call_select>, arg=arg@entry=0x7ffce407d420) at alloc.c:5103
#6  0x00000000006489f9 in thread_select (func=<optimized out>, max_fds=max_fds@entry=11, rfds=rfds@entry=0x7ffce407d500, wfds=wfds@entry=0x7ffce407d580, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffce407db60, sigmask=0x0) at thread.c:602
#7  0x000000000066ad16 in xg_select (fds_lim=11, rfds=rfds@entry=0x7ffce407dc60, wfds=wfds@entry=0x7ffce407dce0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffce407db60, sigmask=sigmask@entry=0x0) at xgselect.c:117
#8  0x0000000000622b61 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=..., wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5384
#9  0x000000000042931b in sit_for (timeout=..., reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5801
#10 0x000000000054c241 in read_char (commandflag=commandflag@entry=1, map=..., map@entry=XIL(0x413a593), prev_event=..., used_mouse_menu=used_mouse_menu@entry=0x7ffce407e5bb, end_time=end_time@entry=0x0) at keyboard.c:2688
#11 0x000000000054de99 in read_key_sequence (keybuf=keybuf@entry=0x7ffce407e700, prompt=..., prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:9108
#12 0x000000000054fc0e in command_loop_1 () at keyboard.c:1338
#13 0x00000000005cc4df in internal_condition_case (bfun=bfun@entry=0x54f9b0 <command_loop_1>, handlers=..., handlers@entry=XIL(0x5340), hfun=hfun@entry=0x542070 <cmd_error>) at eval.c:1349
#14 0x000000000053de38 in command_loop_2 (ignore=..., ignore@entry=XIL(0)) at keyboard.c:1079
#15 0x00000000005cc403 in internal_catch (tag=..., func=func@entry=0x53de10 <command_loop_2>, arg=..., arg@entry=XIL(0)) at eval.c:1114
#16 0x000000000053e06b in command_loop () at keyboard.c:1058
#17 0x0000000000541b74 in recursive_edit_1 () at keyboard.c:703
#18 0x0000000000541f3e in Frecursive_edit () at keyboard.c:774
#19 0x000000000041bfb2 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1756

Thread 5 (Thread 0x7f8722610700 (LWP 27981)):
#0  temp_set_point_both (buffer=0xdb5800 <bss_sbrk_buffer+458720>, charpos=charpos@entry=146, bytepos=bytepos@entry=146) at intervals.c:1729
#1  0x00000000006356ed in set_point_both (charpos=<optimized out>, bytepos=146) at intervals.c:1997
#2  0x0000000000635f08 in set_point_from_marker (marker=..., marker@entry=XIL(0x3e59fc5)) at intervals.c:1771
#3  0x00000000005bbf32 in Fgoto_char (position=..., position@entry=XIL(0x3e59fc5)) at editfns.c:423
#4  0x00000000005c6920 in save_excursion_restore (marker=XIL(0x3e59fc5), window=...) at editfns.c:1023
#5  0x00000000005cce89 in unbind_to (count=<optimized out>, value=..., value@entry=XIL(0)) at eval.c:3593
#6  0x000000000061510f in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260a0b8) at bytecode.c:652
#7  0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f8722609d30), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260a0b8) at eval.c:3023
#8  0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=0x7f872260a0b0) at eval.c:2836
#9  0x00000000005cd755 in Fapply (nargs=2, args=<optimized out>) at eval.c:2442
#10 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260a1e8) at eval.c:2822
#11 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7f872260a498) at bytecode.c:632
#12 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260a218), nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7f872260a498) at eval.c:3023
#13 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=4, args=0x7f872260a490) at eval.c:2836
#14 0x00000000005cd755 in Fapply (nargs=3, args=<optimized out>) at eval.c:2442
#15 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260a640) at eval.c:2822
#16 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7f872260b688) at bytecode.c:632
#17 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260a6b8), nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7f872260b688) at eval.c:3023
#18 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7f872260b680) at eval.c:2836
#19 0x00000000005d1864 in call3 (fn=..., arg1=..., arg2=..., arg3=...) at eval.c:2689
#20 0x00000000005cf2f3 in funcall_subr (subr=0x900720 <Sfile_attributes>, numargs=numargs@entry=2, args=args@entry=0x7f872260b7e0) at eval.c:2899
#21 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260b7d8) at eval.c:2822
#22 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260bbb0) at bytecode.c:632
#23 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260b818), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260bbb0) at eval.c:3023
#24 0x00000000005cd41d in Ffuncall (nargs=3, args=args@entry=0x7f872260bba8) at eval.c:2836
#25 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7f872260bff8) at bytecode.c:632
#26 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260bbd0), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7f872260bff8) at eval.c:3023
#27 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7f872260bff0) at eval.c:2836
#28 0x00000000005cd809 in Fapply (nargs=2, args=0x7f872260bff0) at eval.c:2399
#29 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260bfe8) at eval.c:2822
#30 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260c420) at bytecode.c:632
#31 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260c018), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260c420) at eval.c:3023
#32 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260c418) at eval.c:2836
#33 0x00000000005cd809 in Fapply (nargs=3, args=0x7f872260c418) at eval.c:2399
#34 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260c410) at eval.c:2822
#35 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260d458) at bytecode.c:632
#36 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260c488), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260d458) at eval.c:3023
#37 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260d450) at eval.c:2836
#38 0x00000000005cd5cf in call2 (fn=..., arg1=..., arg2=...) at eval.c:2681
#39 0x00000000005cf2fe in funcall_subr (subr=0x9000a0 <Sfile_readable_p>, numargs=numargs@entry=1, args=args@entry=0x7f872260d578) at eval.c:2897
#40 0x00000000005cd4af in Ffuncall (nargs=2, args=args@entry=0x7f872260d570) at eval.c:2822
#41 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7f872260d8f8) at bytecode.c:632
#42 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260d580), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7f872260d8f8) at eval.c:3023
#43 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7f872260d8f0) at eval.c:2836
#44 0x00000000005cd809 in Fapply (nargs=2, args=0x7f872260d8f0) at eval.c:2399
#45 0x00000000005cd4af in Ffuncall (nargs=3, args=args@entry=0x7f872260d8e8) at eval.c:2822
#46 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260dd20) at bytecode.c:632
#47 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260d918), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260dd20) at eval.c:3023
#48 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260dd18) at eval.c:2836
#49 0x00000000005cd809 in Fapply (nargs=3, args=0x7f872260dd18) at eval.c:2399
#50 0x00000000005cd4af in Ffuncall (nargs=4, args=args@entry=0x7f872260dd10) at eval.c:2822
#51 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260ed58) at bytecode.c:632
#52 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260dd88), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260ed58) at eval.c:3023
#53 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7f872260ed50) at eval.c:2836
#54 0x00000000005cd5cf in call2 (fn=..., arg1=..., arg1@entry=XIL(0x5940), arg2=..., arg2@entry=XIL(0x7f8718024484)) at eval.c:2681
#55 0x0000000000582b87 in Ffile_accessible_directory_p (filename=...) at fileio.c:2825
#56 0x00000000005cf2fe in funcall_subr (subr=0x8fff60 <Sfile_accessible_directory_p>, numargs=numargs@entry=1, args=args@entry=0x7f872260eec8) at eval.c:2897
#57 0x00000000005cd4af in Ffuncall (nargs=2, args=args@entry=0x7f872260eec0) at eval.c:2822
#58 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=2, args=<optimized out>, args@entry=0x7f872260f218) at bytecode.c:632
#59 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260ef08), nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7f872260f218) at eval.c:3023
#60 0x00000000005cd41d in Ffuncall (nargs=3, args=args@entry=0x7f872260f210) at eval.c:2836
#61 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=5, args=<optimized out>, args@entry=0x7f872260f7e0) at bytecode.c:632
#62 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260f278), nargs=nargs@entry=5, arg_vector=arg_vector@entry=0x7f872260f7e0) at eval.c:3023
#63 0x00000000005cd41d in Ffuncall (nargs=6, args=args@entry=0x7f872260f7d8) at eval.c:2836
#64 0x0000000000615150 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=0, args=<optimized out>, args@entry=0x3fd50a8) at bytecode.c:632
#65 0x00000000005d09fc in funcall_lambda (fun=XIL(0x7f872260f808), nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x3fd50a8) at eval.c:3023
#66 0x00000000005cd41d in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x3fd50a0) at eval.c:2836
#67 0x00000000006473db in invoke_thread_function () at thread.c:684
#68 0x00000000005cc4df in internal_condition_case (bfun=bfun@entry=0x6473a0 <invoke_thread_function>, handlers=..., handlers@entry=XIL(0xc330), hfun=hfun@entry=0x6472c0 <record_thread_error>) at eval.c:1349
#69 0x0000000000647e01 in run_thread (state=0x3fd5080) at thread.c:723
#70 0x00007f87384772a7 in start_thread () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#71 0x00007f8737b1457f in clone () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libc.so.6
warning: Unknown thread 6
warning: Unknown thread 7
warning: Unknown thread 8
warning: Unknown thread 9
warning: Unknown thread 10
warning: Unknown thread 11
warning: Unknown thread 12
warning: Unknown thread 13
warning: Unknown thread 14
warning: Unknown thread 15
[Switching to Thread 0x7f873eb61b40 (LWP 27888)]

Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=147,
    bytepos=147) at intervals.c:1826
1826	{
$40 = (struct thread_state *) 0xd45600 <main_thread>
"electric-indent-post-self-insert-function" (0xe407de80)
"self-insert-command" (0xe407e080)
"funcall-interactively" (0xe407e078)
"call-interactively" (0xe407e350)
"command-execute" (0xe407e668)

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Thu, 30 Aug 2018 11:49:27 -0700
> 
> Printing the C-level backtraces on every breakpoint makes Emacs under
> gdb too slow to let me reproduce the bug, so I came up with this
> compromise:
> 
> break set_point_both if current_thread->m_current_buffer == $1
> commands
> p current_thread
> xbacktrace
> if current_thread != &main_thread
>   thread apply 1 5-15 backtrace

The "backtrace" command accepts an argument, the number of frames to
show; so you could use "backtrace 10" to show just the innermost 10
frames, and thus make the backtrace be faster.

> Thread 1 (Thread 0x7f873eb61b40 (LWP 27888)):
> #0  0x00007f87384808cc in __lll_lock_wait () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
> #1  0x00007f8738479a45 in pthread_mutex_lock () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
> #2  0x0000000000648df9 in sys_mutex_lock (mutex=mutex@entry=0xd455c0 <global_lock>) at systhread.c:137
> #3  0x0000000000647582 in acquire_global_lock (self=0xd45600 <main_thread>) at thread.c:100

This thread, the main thread, is waiting for the global lock to become
free.

> Thread 5 (Thread 0x7f8722610700 (LWP 27981)):
> #0  set_point_both (charpos=146, bytepos=146) at intervals.c:1826
> #1  0x0000000000635f08 in set_point_from_marker (marker=..., marker@entry=XIL(0x3e59fc5)) at intervals.c:1771
> #2  0x00000000005bbf32 in Fgoto_char (position=..., position@entry=XIL(0x3e59fc5)) at editfns.c:423
> #3  0x00000000005c6920 in save_excursion_restore (marker=XIL(0x3e59fc5), window=...) at editfns.c:1023
> #4  0x00000000005cce89 in unbind_to (count=<optimized out>, value=..., value@entry=XIL(0)) at eval.c:3593

This thread is restoring point as part as returning from
save-excursion.  But I still am not sure whether this is our villain.
Does buffer position 146 sound correct wrt what you see in *scratch*,
i.e. is it the position where point jumps?  Also, please add to the
breakpoint commands the command to display the current buffer:

   pp current_buffer->name_

Thanks.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

> But I still am not sure whether this is our villain.
> Does buffer position 146 sound correct wrt what you see in *scratch*,
> i.e. is it the position where point jumps?  Also, please add to the
> breakpoint commands the command to display the current buffer:
>
>    pp current_buffer->name_
>
> Thanks.

The case against our suspect keeps getting stronger.  The following is
an excerpt from a gdb session where I added to the breakpoint commands
printing the current buffer name and single-line C-level backtraces of
the threads when the main thread is current.  I also verified that the
position and distance that point jumped matched what I saw in *scratch*.


Thread 1 "find-file /scp:" hit Breakpoint 5, set_point_both (charpos=259, 
    bytepos=259) at intervals.c:1826
1826	{
$379 = (struct thread_state *) 0xd405a0 <main_thread>
"*scratch*"
"electric-indent-post-self-insert-function" (0xfffef670)
"self-insert-command" (0xfffef890)
"funcall-interactively" (0xfffef888)
"call-interactively" (0xfffefb70)
"command-execute" (0xfffefe28)

Thread 1 (Thread 0x7ffff7fc0b40 (LWP 15726)):
#0  set_point_both (charpos=259, bytepos=259) at intervals.c:1826

Thread 5 (Thread 0x7fffdbfff700 (LWP 15839)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 6 (Thread 0x7fffdb7fe700 (LWP 15840)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 7 (Thread 0x7fffdaffd700 (LWP 15841)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 8 (Thread 0x7fffda7fc700 (LWP 15842)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 9 (Thread 0x7fffd9ffb700 (LWP 15843)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 10 (Thread 0x7fffd97fa700 (LWP 15844)):
#0  0x00007ffff18e48cc in __lll_lock_wait () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0

Thread 11 (Thread 0x7fffd8ff9700 (LWP 15960)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
warning: Unknown thread 12
warning: Unknown thread 13
warning: Unknown thread 14
warning: Unknown thread 15
[Switching to Thread 0x7fffd97fa700 (LWP 15844)]

Thread 10 "find-file-nosel" hit Breakpoint 5, set_point_both (charpos=256, 
    bytepos=256) at intervals.c:1826
1826	{
$380 = (struct thread_state *) 0x38b3c80
"*scratch*"
"tramp-sh-handle-file-attributes" (0xd97f36e8)
"apply" (0xd97f36e0)
"tramp-sh-file-name-handler" (0xd97f3ac0)
"apply" (0xd97f3ab8)
"tramp-file-name-handler" (0xd97f49f8)
"file-attributes" (0xd97f4b28)
"tramp-handle-file-symlink-p" (0xd97f4e58)
"apply" (0xd97f4e50)
"tramp-sh-file-name-handler" (0xd97f5230)
"apply" (0xd97f5228)
"tramp-file-name-handler" (0xd97f6168)
"file-symlink-p" (0xd97f6310)
"tramp-sh-handle-file-truename" (0xd97f7be8)
"apply" (0xd97f7be0)
"tramp-sh-file-name-handler" (0xd97f7fc0)
"apply" (0xd97f7fb8)
"tramp-file-name-handler" (0xd97f8f28)
"file-truename" (0xd97f9308)
"find-file-noselect" (0xd97f9870)
0x38b0f10 PVEC_COMPILED

Thread 1 (Thread 0x7ffff7fc0b40 (LWP 15726)):
#0  0x00007ffff18e48cc in __lll_lock_wait () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00007ffff18dda45 in pthread_mutex_lock () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#2  0x0000000000644109 in sys_mutex_lock (mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:137
#3  0x00000000006427f2 in acquire_global_lock (self=0xd405a0 <main_thread>) at thread.c:100
#4  really_call_select (arg=arg@entry=0x7ffffffeec00) at thread.c:582
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x642760 <really_call_select>, arg=arg@entry=0x7ffffffeec00) at alloc.c:5019
#6  0x0000000000643bb9 in thread_select (func=<optimized out>, max_fds=max_fds@entry=8, rfds=rfds@entry=0x7ffffffeece0, wfds=wfds@entry=0x7ffffffeed60, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffffffef340, sigmask=0x0) at thread.c:602
#7  0x0000000000665a06 in xg_select (fds_lim=8, rfds=rfds@entry=0x7ffffffef440, wfds=wfds@entry=0x7ffffffef4c0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffffffef340, sigmask=sigmask@entry=0x0) at xgselect.c:117
#8  0x000000000061e708 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=..., wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5384
#9  0x00000000004290f7 in sit_for (timeout=..., reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5810

Thread 5 (Thread 0x7fffdbfff700 (LWP 15839)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x38ced70, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x38ced60, locker=0x38aec80, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x38ced50) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x38ced55)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffdbffce68) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffdbffce60) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x3751848) at bytecode.c:632

Thread 6 (Thread 0x7fffdb7fe700 (LWP 15840)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x38ced70, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x38ced60, locker=0x38afc80, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x38ced50) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x38ced55)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffdb7fc158) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffdb7fc150) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x3751848) at bytecode.c:632

Thread 7 (Thread 0x7fffdaffd700 (LWP 15841)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x38ced70, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x38ced60, locker=0x38b0c80, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x38ced50) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x38ced55)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffdaffb1b8) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffdaffb1b0) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x3751848) at bytecode.c:632

Thread 8 (Thread 0x7fffda7fc700 (LWP 15842)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x38ced70, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x38ced60, locker=0x38b1c80, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x38ced50) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x38ced55)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffda7fa1b8) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffda7fa1b0) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x3751848) at bytecode.c:632

Thread 9 (Thread 0x7fffd9ffb700 (LWP 15843)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x38ced70, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x38ced60, locker=0x38b2c80, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x38ced50) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x38ced55)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffd9ff91b8) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffd9ff91b0) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=3, args=<optimized out>, args@entry=0x3751848) at bytecode.c:632

Thread 10 (Thread 0x7fffd97fa700 (LWP 15844)):
#0  set_point_both (charpos=256, bytepos=256) at intervals.c:1826
#1  0x0000000000631896 in set_point_from_marker (marker=...) at intervals.c:1771
#2  0x00000000005b82d5 in Fgoto_char (position=..., position@entry=XIL(0x7fffc000f4f5)) at editfns.c:423
#3  0x00000000005c2dc0 in save_excursion_restore (marker=XIL(0x7fffc000f4f5), window=...) at editfns.c:1023
#4  0x00000000005c9309 in unbind_to (count=<optimized out>, value=..., value@entry=XIL(0)) at eval.c:3593
#5  0x0000000000610fff in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=1, args=<optimized out>, args@entry=0x373ca88) at bytecode.c:652
#6  0x00000000005ccfc2 in funcall_lambda (fun=XIL(0x7fffd97f3270), nargs=nargs@entry=1, arg_vector=0x373ca88, arg_vector@entry=0x7fffd97f36e8) at eval.c:3023
#7  0x00000000005c981b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffd97f36e0) at eval.c:2836
#8  0x00000000005c9caf in Fapply (nargs=2, args=0x7fffd97f36e0) at eval.c:2399
#9  0x00000000005c9931 in Ffuncall (nargs=3, args=args@entry=0x7fffd97f36d8) at eval.c:2822

Thread 11 (Thread 0x7fffd8ff9700 (LWP 15960)):
#0  0x00007ffff18e158f in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libpthread.so.0
#1  0x00000000006441c9 in sys_cond_wait (cond=cond@entry=0x1320fa0 <bss_sbrk_buffer+6162400>, mutex=mutex@entry=0xd40560 <global_lock>) at systhread.c:163
#2  0x000000000064337f in lisp_mutex_lock_for_thread (mutex=0x1320f90 <bss_sbrk_buffer+6162384>, locker=0x7fffbc061490, new_count=0) at thread.c:174
#3  0x0000000000643459 in lisp_mutex_lock (new_count=0, mutex=<optimized out>) at thread.c:189
#4  mutex_lock_callback (arg=<optimized out>) at thread.c:283
#5  0x00000000005a6d78 in flush_stack_call_func (func=func@entry=0x643440 <mutex_lock_callback>, arg=arg@entry=0x1320f80 <bss_sbrk_buffer+6162368>) at alloc.c:5019
#6  0x0000000000642db5 in Fmutex_lock (mutex=XIL(0x1320f85)) at thread.c:311
#7  0x00000000005cb72e in funcall_subr (subr=0xca94c0 <Smutex_lock>, numargs=numargs@entry=1, args=args@entry=0x7fffd8ff8710) at eval.c:2897
#8  0x00000000005c9931 in Ffuncall (nargs=2, args=args@entry=0x7fffd8ff8708) at eval.c:2822
#9  0x0000000000611040 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., args_template@entry=XIL(0), nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:632
warning: Unknown thread 12
warning: Unknown thread 13
warning: Unknown thread 14
warning: Unknown thread 15

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Fri, 31 Aug 2018 09:52:45 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But I still am not sure whether this is our villain.
> > Does buffer position 146 sound correct wrt what you see in *scratch*,
> > i.e. is it the position where point jumps?  Also, please add to the
> > breakpoint commands the command to display the current buffer:
> >
> >    pp current_buffer->name_
> >
> > Thanks.
> 
> The case against our suspect keeps getting stronger.  The following is
> an excerpt from a gdb session where I added to the breakpoint commands
> printing the current buffer name and single-line C-level backtraces of
> the threads when the main thread is current.  I also verified that the
> position and distance that point jumped matched what I saw in *scratch*.
> [...]
> Thread 10 "find-file-nosel" hit Breakpoint 5, set_point_both (charpos=256, 
>     bytepos=256) at intervals.c:1826
> 1826	{
> $380 = (struct thread_state *) 0x38b3c80
> "*scratch*"
> "tramp-sh-handle-file-attributes" (0xd97f36e8)
> "apply" (0xd97f36e0)
> "tramp-sh-file-name-handler" (0xd97f3ac0)
> "apply" (0xd97f3ab8)
> "tramp-file-name-handler" (0xd97f49f8)
> "file-attributes" (0xd97f4b28)
> "tramp-handle-file-symlink-p" (0xd97f4e58)
> "apply" (0xd97f4e50)
> "tramp-sh-file-name-handler" (0xd97f5230)
> "apply" (0xd97f5228)
> "tramp-file-name-handler" (0xd97f6168)
> "file-symlink-p" (0xd97f6310)
> "tramp-sh-handle-file-truename" (0xd97f7be8)
> "apply" (0xd97f7be0)
> "tramp-sh-file-name-handler" (0xd97f7fc0)
> "apply" (0xd97f7fb8)
> "tramp-file-name-handler" (0xd97f8f28)
> "file-truename" (0xd97f9308)
> "find-file-noselect" (0xd97f9870)
> 0x38b0f10 PVEC_COMPILED
> 
> Thread 10 (Thread 0x7fffd97fa700 (LWP 15844)):
> #0  set_point_both (charpos=256, bytepos=256) at intervals.c:1826
> #1  0x0000000000631896 in set_point_from_marker (marker=...) at intervals.c:1771
> #2  0x00000000005b82d5 in Fgoto_char (position=..., position@entry=XIL(0x7fffc000f4f5)) at editfns.c:423
> #3  0x00000000005c2dc0 in save_excursion_restore (marker=XIL(0x7fffc000f4f5), window=...) at editfns.c:1023
> #4  0x00000000005c9309 in unbind_to (count=<optimized out>, value=..., value@entry=XIL(0)) at eval.c:3593

OK, but this sounds strange to me, since AFAICT Tramp switches to its
own buffer when it sends a script to the remote and waits for it to
return the results (which is most probably when the main thread gets
control and lets you type).

Michael, how come Tramp moves point in the *scratch* buffer in this
scenario?

Thanks.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, but this sounds strange to me, since AFAICT Tramp switches to its
> own buffer when it sends a script to the remote and waits for it to
> return the results (which is most probably when the main thread gets
> control and lets you type).
>
> Michael, how come Tramp moves point in the *scratch* buffer in this
> scenario?

It shouldn't. Will check.

> Thanks.

Best regards, Michael.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, but this sounds strange to me, since AFAICT Tramp switches to its
> own buffer when it sends a script to the remote and waits for it to
> return the results (which is most probably when the main thread gets
> control and lets you type).
>
> Michael, how come Tramp moves point in the *scratch* buffer in this
> scenario?

Here's what I think the sequence of events was, in that last trace:

When tramp-sh-handle-file-attributes is called in Thread 10, its current
buffer is *scratch*.  Point in *scratch* is 256.

tramp-sh-handle-file-attributes enters its save-excursion form which
saves a marker pointing to 256 in *scratch* in the special binding stack
of Thread 10.

tramp-sh-handle-file-attributes then calls functions which switch to
Tramp's buffer, and which yield execution while waiting for the remote.

The main thread gains the global lock and handles 3 characters of
keyboard input, which all run self-insert-command in the main thread's
current buffer, *scratch*.  Point is now 259 but the marker in Thread
10's stack is still at 256.

The main thread yields in between keystrokes and Thread 10 resumes when
the response is received from the remote.  When its execution reaches
the end of the save-excursion form, save_excursion_restore sets the
current buffer and its point from the marker, to *scratch* and 256.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: Michael Albinus <michael.albinus@gmx.de>,  32537@debbugs.gnu.org
> Date: Sat, 01 Sep 2018 17:24:49 -0700
> 
> > Michael, how come Tramp moves point in the *scratch* buffer in this
> > scenario?
> 
> Here's what I think the sequence of events was, in that last trace:
> 
> When tramp-sh-handle-file-attributes is called in Thread 10, its current
> buffer is *scratch*.  Point in *scratch* is 256.
> 
> tramp-sh-handle-file-attributes enters its save-excursion form which
> saves a marker pointing to 256 in *scratch* in the special binding stack
> of Thread 10.

Why does it call save-excursion if it is going to switch to another
buffer?  The call to save-excursion is only needed if the program is
about to move point in the current buffer.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> tramp-sh-handle-file-attributes enters its save-excursion form which
>> saves a marker pointing to 256 in *scratch* in the special binding stack
>> of Thread 10.
>
> Why does it call save-excursion if it is going to switch to another
> buffer?  The call to save-excursion is only needed if the program is
> about to move point in the current buffer.

Don't know. Several save-excursion calls are there for decades. They
didn't hurt until now (maybe some slight performance penalties).

I've removed some of them, where it looks appropriate. Pushed to the
feature/tramp-thread-safe branch. tramp-tests still pass successfully,
and the error as described in this bug didn't happen any more for me.

I've checked also the other tramp*.el files, but there isn't any
suspicious save-excursion use.

Gemini, could you pls crosscheck that it is fixed?

Thanks, and best regards, Michael.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Gemini Lasswell]

Michael Albinus <michael.albinus@gmx.de> writes:

> Gemini, could you pls crosscheck that it is fixed?

Yes, it is fixed.  Thanks.

bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Michael Albinus]

Version: 27.1

Gemini Lasswell <gazally@runbox.com> writes:

> Yes, it is fixed.  Thanks.

Thanks, I'm closing the bug.

Best regards, Michael.