bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

Hi. I see this problem often in everyday use of emacs, but every time I
try to construct a reliable reproducing recipe, it always works ok, so
some of this report is a request for debugging help.

I've seen this sort of bug for years, so probably it exists in the
latest emacs. Today I'm seeing it in a build from a few weeks ago:
553ad9c9e85 built on 20210716. I don't know how to reproduce in the
latest emacs. In the session I have running (from the 20210716 build) I
have a shell buffer that shows the problem 100% of the time. New shell
buffers do not show this problem.

A recipe that should work:

1. emacs
   Run emacs. Possibly my config is triggering it. I don't know

2. C-x C-f /ssh:server:
   Open a remote TRAMP connection

3. M-x shell
   Open a remote shell

4. cat
   Run a "cat" command in the remote shell

5. C-c C-c
   kill the "cat"

In fresh emacs sessions and fresh shell buffers this works fine: the
"cat" process is killed and we get back to the prompt. Something happens
with older shell buffers where the child process is NOT killed, and
emacs complains with "Forbidden reentrant call of Tramp"

I just tried to (setq tramp-verbose 10) to get a debug log of the
failure. It says this:

  ;; Emacs: 28.0.50 Tramp: 2.5.1 -*- mode: outline; coding: utf-8; -*-
  ;; Location: /usr/share/emacs/28.0.50/lisp/net/tramp.el.gz Git: /
  01:49:39.391745 tramp-interrupt-process (5) # Interrupt process shell<6> with pid 3705628
  01:49:39.391864 tramp-get-connection-property (7) # null-device /dev/null; cache used: t
  01:49:39.391946 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.392019 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.392089 tramp-get-connection-property (7) # process-buffer nil; cache used: nil
  01:49:39.392180 tramp-get-connection-property (7) # last-cmd-time (24848 60388 520023 896000); cache used: t
  01:49:39.392262 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.392325 tramp-get-connection-property (7) # remote-echo nil; cache used: nil
  01:49:39.392385 tramp-send-command (6) # echo are you awake
  01:49:39.392447 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.392509 tramp-get-connection-property (7) # chunksize 0; cache used: t
  01:49:39.392573 tramp-set-connection-property (7) # last-cmd-time (24848 60451 392543 712000)
  01:49:39.392637 tramp-send-string (10) # echo are you awake
  01:49:39.392698 tramp-get-connection-property (7) # process-buffer nil; cache used: nil
  01:49:39.392775 tramp-get-connection-property (7) # locked nil; cache used: nil
  01:49:39.392828 tramp-set-connection-property (7) # locked t
  01:49:39.392912 tramp-flush-connection-property (7) # locked
  01:49:39.392981 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.393036 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.393120 tramp-get-connection-property (7) # locked nil; cache used: nil
  01:49:39.393173 tramp-set-connection-property (7) # locked t
  01:49:39.441305 tramp-accept-process-output (10) # *tramp/ssh fatty* nil run t
  are you awake
  ///66c246702753a7fa497f74164e69b140#$
  01:49:39.441619 tramp-flush-connection-property (7) # locked
  01:49:39.441783 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.441931 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.442103 tramp-wait-for-regexp (6) # 
  are you awake
  ///66c246702753a7fa497f74164e69b140#$
  01:49:39.442387 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.442556 tramp-get-connection-property (7) # remote-echo nil; cache used: nil
  01:49:39.442710 tramp-send-command (6) # (\kill -2 -3705628 || \kill -2 3705628) 2>/dev/null
  01:49:39.442872 tramp-get-connection-property (7) # process-name nil; cache used: nil
  01:49:39.443034 tramp-get-connection-property (7) # chunksize 0; cache used: t
  01:49:39.443204 tramp-set-connection-property (7) # last-cmd-time (24848 60451 443130 172000)
  01:49:39.443376 tramp-send-string (10) # (\kill -2 -3705628 || \kill -2 3705628) 2>/dev/null
  01:49:39.443589 tramp-get-connection-property (7) # process-buffer nil; cache used: nil
  01:49:39.443792 tramp-get-connection-property (7) # locked nil; cache used: nil
  01:49:39.443936 tramp-set-connection-property (7) # locked t
  01:49:39.444124 tramp-flush-connection-property (7) # locked
  01:49:39.444293 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.444433 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.444579 tramp-get-connection-property (7) # locked nil; cache used: nil
  01:49:39.444719 tramp-set-connection-property (7) # locked t
  01:49:39.493255 tramp-accept-process-output (10) # *tramp/ssh fatty* nil run t
  ///66c246702753a7fa497f74164e69b140#$
  01:49:39.493535 tramp-flush-connection-property (7) # locked
  01:49:39.493687 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.493835 tramp-get-connection-property (7) # check-remote-echo nil; cache used: nil
  01:49:39.494001 tramp-wait-for-regexp (6) # 
  ///66c246702753a7fa497f74164e69b140#$
  01:49:39.494263 tramp-get-connection-property (7) # locked t; cache used: t
  01:49:39.512596 tramp-accept-process-output (10) # 
    backtrace()
    tramp-error(#<process shell<6>> remote-file-error "Forbidden reentrant call of Tramp")
    tramp-accept-process-output(#<process shell<6>> 0)
    tramp-interrupt-process(nil t)
    comint-interrupt-subjob()
    funcall-interactively(comint-interrupt-subjob)
    command-execute(comint-interrupt-subjob)
  01:49:41.733242 tramp-accept-process-output


If I open a fresh shell in the same emacs session, it works OK. That
debug log is similar, except the last tramp-get-connection-property line says:

  01:48:36.571873 tramp-get-connection-property (7) # locked nil; cache used: nil

I don't know how it's unlocked. Debugging suggestions? Should I just add
more diagnostics in every lock/unlock path? Do we think this may be
fixed in the latest emacs?

Thanks!

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

> Hi.

Hi Dima,

> I don't know how it's unlocked. Debugging suggestions? Should I just add
> more diagnostics in every lock/unlock path? Do we think this may be
> fixed in the latest emacs?

This error message has been added to Tramp 2.5 in order to get more
diagnostics when the problem happens. It is an indication that a remote
opeation has been started asynchronously, from a timer, a process filter
or sentinel, or other asynchronous invocation (like interrupt process).

I don't believe it has been fixed yet in Emacs master, I haven't done
anything in this area for weeks. I'll try to fix your use case, but it
might take time - these days I'm occupied otherwise. Holiday season.

See the respective entry in Tramp's FAQ (info "(tramp) Frequently Asked Questions")

See also the discussion on the Tramp ML
<https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=forbidden&submit=Search%21&idxname=tramp-devel&max=20&result=normal&sort=score>

> Thanks!

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

Hi Michael. There's no rush to work on this. I'll reply here for
whenever you get around to looking at it.

I did some debugging, and it appears that the tramp property-caching
mechanism is failing. We exit the (with-tramp-locked-connection ...)
form, but when we try to enter the next (with-tramp-locked-connection
...) form, it looks locked because

(tramp-get-connection-property proc "locked" nil)

is evaluating to t. I instrumented (tramp-get-connection-property), and
I can see that this t comes from the property cache. I can "fix" the bug
by removing the

    (when (and (not (eq cached tramp-cache-undefined))
	       ;; If the key is an auxiliary process object, check
	       ;; whether the process is still alive.
	       (not (and (processp key) (not (process-live-p key)))))
      (setq value cached
	    cache-used t))

form from (tramp-get-connection-property)

Can I get the intent of this form? Are you trying to use this form if
the process is alive, or if the process is dead? My process is very much
alive, so this form is being used. Is this what we want?

If it is what we want, then the cached value of t is the problem. I
haven't looked into why that's happening yet.

Thanks!

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

> Hi Michael.

Hi Dima,

> I did some debugging, and it appears that the tramp property-caching
> mechanism is failing. We exit the (with-tramp-locked-connection ...)
> form, but when we try to enter the next (with-tramp-locked-connection
> ...) form, it looks locked because
>
> (tramp-get-connection-property proc "locked" nil)
>
> is evaluating to t. I instrumented (tramp-get-connection-property), and
> I can see that this t comes from the property cache. I can "fix" the bug
> by removing the
>
>     (when (and (not (eq cached tramp-cache-undefined))
> 	       ;; If the key is an auxiliary process object, check
> 	       ;; whether the process is still alive.
> 	       (not (and (processp key) (not (process-live-p key)))))
>       (setq value cached
> 	    cache-used t))
>
> form from (tramp-get-connection-property)
>
> Can I get the intent of this form? Are you trying to use this form if
> the process is alive, or if the process is dead? My process is very much
> alive, so this form is being used. Is this what we want?

No, I believe the mechanism is working correctly. A lock is placed on
the connection process of Tramp, and it is kept until the related
operation has finished. The process is expected to be alive, the
additional check of process-live-p is just a reassurance.

> If it is what we want, then the cached value of t is the problem. I
> haven't looked into why that's happening yet.

The problem is the following: Tramp sends a (shell) command to the
remote host, and waits for the reply. This must be atomic, no other
command shall be sent in parallel, in order to get the proper reply.

If there is asynchronous code running, from a timer, a process filter or
sentinel, or process interrupt, this can happen: a second command is
sent, while the other command didn't get its reply yet. The macro
with-tramp-locked-connection shall protect us in this case, and it
raises the respective error. That's not a perfect solution. A better way
would do use threads with mutexes, so that the second command can wait
until the first command got its reply. Something like this needs to be
implemented.

> Thanks!

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

Hi Michael.

So I've seen this a number of times now, and it really looks like the
caching mechanism is the problem. Every time I see "Forbidden reentrant
call of Tramp" when trying to C-c C-c a remote process, I re-evaluate
tramp-get-connection-property with

  (when (and (not (eq cached tramp-cache-undefined))
             ;; If the key is an auxiliary process object, check
             ;; whether the process is still alive.
             (not (and (processp key) (not (process-live-p key)))))
    (setq value cached
          cache-used t))

removed. This effectively disables the caching mechanism. Then I can C-c
C-c my process, and it dies like it's supposed to. TRAMP feels slower
after than, as expected, so I put tramp-get-connection-property back to
what it was. Eventually the problem comes back, and I do the same dance
to "fix" it.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

> Hi Michael.

Hi Dima,

> So I've seen this a number of times now, and it really looks like the
> caching mechanism is the problem.

No, it isn't. Tramp uses its cache just as memory. The problem is
somewhere else, see below.

> Every time I see "Forbidden reentrant call of Tramp" when trying to
> C-c C-c a remote process, I re-evaluate tramp-get-connection-property
> with
>
>   (when (and (not (eq cached tramp-cache-undefined))
>              ;; If the key is an auxiliary process object, check
>              ;; whether the process is still alive.
>              (not (and (processp key) (not (process-live-p key)))))
>     (setq value cached
>           cache-used t))
>
> removed. This effectively disables the caching mechanism. Then I can C-c
> C-c my process, and it dies like it's supposed to. TRAMP feels slower
> after than, as expected, so I put tramp-get-connection-property back to
> what it was. Eventually the problem comes back, and I do the same dance
> to "fix" it.

The Tramp manual tells you how to bypass the problem, see Frequently
Asked Questions:

--8<---------------cut here---------------start------------->8---
   • I get an error ‘Remote file error: Forbidden reentrant call of
     Tramp’

     Timers, process filters and sentinels, and other event based
     functions can run at any time, when a remote file operation is
     still running.  This can cause TRAMP to block.  When such a
     situation is detected, this error is triggered.  It should be fixed
     in the respective function (sending an error report will help), but
     for the time being you can suppress this error by the following
     code in your ‘~/.emacs’:

          (setq debug-ignored-errors
                (cons 'remote-file-error debug-ignored-errors))
--8<---------------cut here---------------end--------------->8---

In order to understand the problem, let's assume the following scenario:

- You have connected to a remote host, say "/ssh:host:". Tramp uses
  internally the process *tramp/ssh host* for communicating with that
  process.

- You have also started another asynchronous process to that remote
  host.

- Now, while normal use of Emacs, the function (file-attributes
  "/ssh:host:/path/to/file") is called. Tramp sends a command to the
  process *tramp/ssh host*, like "stat /path/to/file".

- While Tramp waits for the answer of the "stat ..." command, your other
  process has finished. It might have a process sentinel, which is
  called exactly at this time, because Tramp is in a loop
  (accept-process-output ...).

- This process filter might trigger another file operation, like
  (delete-file "/ssh:host:/tmp/tmpfile"). This would require to send
  another command to the *tramp/ssh host* process like "rm -f /tmp/tmpfile".

- Since the first command, "stat ...", hasn't been finished, this would
  result in inconsistencies. Tramp detects this situation, and raises
  the "Forbidden reentrant call of Tramp" error.

Not so easy to solve. Ideally, remote file name functions initiated in
process filters, process sentinels, timers and alike shall wait, until
the currently executed remote command has finished. Don't know how to
achieve this.

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

Thanks for the explanation. What would be an example of an asynchronous
process? I have several remote 'M-x shell' buffers and probably some
dired buffers looking at remote directories. Is each 'M-x shell' child
an "asynchronous process" for the purposes of this issue?

Does it make sense to you that disabling caching fixes it?

Usually, I can C-c in "M-x shell" just fine. When this bug is triggered,
though, I cannot C-c in remote M-x shell processes at all: it fails each
time. Disabling the caching, getting one successful C-c, and re-enabling
it makes it work that time and in the future. Is this consistent with
the failure mechanism you're thinking of?

Thanks

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

I paid more attention to my usage patterns recently. I often have
multiple remote M-x shell buffers going at the same time, using the same
TRAMP connection. One shell might be running a long job, writing stuff
to the console, while I use another shell to do stuff. Could this usage
trigger the race condition you're talking about? If so, setting up an
experiment to try to reproduce the breakage wouldn't be too hard.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

Hi Dima,

> I paid more attention to my usage patterns recently. I often have
> multiple remote M-x shell buffers going at the same time, using the same
> TRAMP connection. One shell might be running a long job, writing stuff
> to the console, while I use another shell to do stuff. Could this usage
> trigger the race condition you're talking about? If so, setting up an
> experiment to try to reproduce the breakage wouldn't be too hard.

I have not the problem to reproduce the bug,
tramp-test44-asynchronous-requests of tramp-tests.el is good enough.

My problem is to find a solution. I'm thinking about using threads, but
there are some hairy details I need to solve first.

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

Hi Dima,

> Thanks for the explanation. What would be an example of an asynchronous
> process? I have several remote 'M-x shell' buffers and probably some
> dired buffers looking at remote directories. Is each 'M-x shell' child
> an "asynchronous process" for the purposes of this issue?

It is an synchronous process, indeed.

> Does it make sense to you that disabling caching fixes it?
>
> Usually, I can C-c in "M-x shell" just fine. When this bug is triggered,
> though, I cannot C-c in remote M-x shell processes at all: it fails each
> time. Disabling the caching, getting one successful C-c, and re-enabling
> it makes it work that time and in the future. Is this consistent with
> the failure mechanism you're thinking of?

Why do you mess with Tramp's cache? Adding remote-file-error to
debug-ignored-errors, as  I have recommended, shall mask the error
sufficiently.

> Thanks

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

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

> Why do you mess with Tramp's cache? Adding remote-file-error to
> debug-ignored-errors, as I have recommended, shall mask the error
> sufficiently.

Tweaking the cache is the method I've found to work, before I knew about
debug-ignored-errors. I'll do what you suggest next time.

Thanks

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

Hi Dima,

>> Why do you mess with Tramp's cache? Adding remote-file-error to
>> debug-ignored-errors, as I have recommended, shall mask the error
>> sufficiently.
>
> Tweaking the cache is the method I've found to work, before I knew about
> debug-ignored-errors. I'll do what you suggest next time.

Thanks! I didn't want to bash you, sorry.

> Thanks

Best regards, Michael.

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Dima Kogan]

Hi. I just hit this error again, and tried to work around it with

  (setq debug-ignored-errors
    (cons 'remote-file-error debug-ignored-errors))

as you suggested. It doesn't work to kill the process, though. I C-c C-c
in my M-x shell, and it fails with a different error:

  tramp-accept-process-output: No catch for tag: non-essential, non-essential

Doing my caching dance actually makes C-c C-c do the right thing. Does
this make sense?

bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp"

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

> Hi.

Hi Dima,

> I just hit this error again, and tried to work around it with
>
>   (setq debug-ignored-errors
>     (cons 'remote-file-error debug-ignored-errors))
>
> as you suggested. It doesn't work to kill the process, though. I C-c C-c
> in my M-x shell, and it fails with a different error:
>
>   tramp-accept-process-output: No catch for tag: non-essential, non-essential
>
> Doing my caching dance actually makes C-c C-c do the right thing. Does
> this make sense?

If the "caching dance" helps you you might continue with this. But I
won't recommend it to the public, I fear too many undesired side-effects.

The best solution would be to fix the problem itself. As always.

Best regards, Michael.

bug#49954: bug#60534: 28.2; Forbidden reentrant call of Tramp

[James Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Albinus wrote:

> In order to understand the problem, let's assume the following scenario:
>
> - You have connected to a remote host, say "/ssh:host:". Tramp uses
>   internally the process *tramp/ssh host* for communicating with that
>   process.
>
> - You have also started another asynchronous process to that remote
>   host.
>
> - Now, while normal use of Emacs, the function (file-attributes
>   "/ssh:host:/path/to/file") is called. Tramp sends a command to the
>   process *tramp/ssh host*, like "stat /path/to/file".
>
> - While Tramp waits for the answer of the "stat ..." command, your other
>   process has finished. It might have a process sentinel, which is
>   called exactly at this time, because Tramp is in a loop
>   (accept-process-output ...).
>
> - This process filter might trigger another file operation, like
>   (delete-file "/ssh:host:/tmp/tmpfile"). This would require to send
>   another command to the *tramp/ssh host* process like "rm -f /tmp/tmpfile".
>
> - Since the first command, "stat ...", hasn't been finished, this would
>   result in inconsistencies. Tramp detects this situation, and raises
>   the "Forbidden reentrant call of Tramp" error.
>
> Not so easy to solve. Ideally, remote file name functions initiated in
> process filters, process sentinels, timers and alike shall wait, until
> the currently executed remote command has finished. Don't know how to
> achieve this.

(This may be an ignorant question, but) if that's so, is it possible to
open a separate connection (perhaps with a ControlPath suffix, and
ControlPersist-ed) in the place of the "Forbidden reentrant call"?

Regards,
James

bug#60534: 28.2; Forbidden reentrant call of Tramp

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

James Thomas <jimjoe@gmx.net> writes:

Hi James,

>> Not so easy to solve. Ideally, remote file name functions initiated in
>> process filters, process sentinels, timers and alike shall wait, until
>> the currently executed remote command has finished. Don't know how to
>> achieve this.
>
> (This may be an ignorant question, but) if that's so, is it possible to
> open a separate connection (perhaps with a ControlPath suffix, and
> ControlPersist-ed) in the place of the "Forbidden reentrant call"?

Not so simple. There is a serious overhead when opening a new
connection, due to the handshaking actions. And it isn't clear to me how
to keep two connections in sync, if (for example) the environment
changes in one of the connections. Be it an environment variable, the
current directory, the availability of a temp file, you name it.

But yes, nobody has tried it yet. My preference is to use threads, so
that one command in a process filter could wait until another command in
the main thread has finished, as example. But the crucial point is, that
you must activate threads in the beginning of a connection. When you
detect, that there is a forbidded reentrant call, it is too late to
activate threads.

> Regards,
> James

Best regards, Michael.

bug#60534: 28.2; Forbidden reentrant call of Tramp

[James Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Albinus wrote:

> Not so simple.

> ...

> And it isn't clear to me how to keep two connections in sync, if (for
> example) the environment changes in one of the connections. Be it an
> environment variable, the current directory, the availability of a
> temp file, you name it.

And here was I thinking that Tramp was mostly remote-state-less beyond
the handshake...

> There is a serious overhead when opening a new connection, due to the
> handshaking actions.

OK; I misremembered for a moment that it was beyond any ControlPersist.

> But yes, nobody has tried it yet. My preference is to use threads, so
> that one command in a process filter could wait until another command
> in the main thread has finished, as example. But the crucial point is,
> that you must activate threads in the beginning of a connection. When
> you detect, that there is a forbidded reentrant call, it is too late
> to activate threads.

Ah, crucial; but not a blocker, I suppose.

Thank you for the effort in explaining, Michael.

Regards,
James

bug#60534: 28.2; Forbidden reentrant call of Tramp

[Georgi Danov]

As discussed in github issue
https://github.com/joaotavora/eglot/issues/859# eglot over tramp throws
"reentrant call" error. This is sympthom of underlying design issue -
 aux libraries use files without being aware of the tramp conection, the
 connection itself has no concurrency control, pooling or other
 multi-user features and without that guard error different tramp clients
 corrupt each other's communication with the language server.

The problem is reproducible by using company mode, probably the language
is not important. In my case it's typescript. Takes 15-30 seconds of
editing and autocomplete to trigger it.

The main congestions seems to happen in file-truename() -- after
displaying candidate company mode goes on to do refresh in the background
and calls file-truename repeatedly while eglot (or someone else) is occupying the tramp
connection. Point is -- the same tramp connection is used by eglot and
any other minor mode that queries file name or state, but they have no
means to share or coordinate this use other than the exception above.

Tramp used to throw more insignificant error in the past and tolerate
the behavior (which corrupts the data exchanged between eglot and the
lsp) and now throws this error. See `with-tramp-locked-connection`
macro. 

I got this problem with other minor modes too, but did not capture the
stack as I lowered the error prio via (add-to-list 'debug-ignored-errors
'remote-file-error). Reading the code would've suggested corruption
won't happen but still garbage was let in the stdio pipe and eglot lost track of the
buffer state.

--------------------------
In GNU Emacs 28.2 (build 1, x86_64-apple-darwin22.1.0, Carbon Version 169 AppKit 2299)
 of 2022-11-24 built on GDMBP.local
Windowing system distributor 'Apple Inc.', version 13.1.0
System Description:  macOS 13.1

Configured using:
 'configure --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-mac/emacs-28.2-mac-9.1/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-mac/emacs-28.2-mac-9.1 --with-mac
 --enable-mac-app=/usr/local/Cellar/emacs-mac/emacs-28.2-mac-9.1
 --with-gnutls --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE PDUMPER THREADS
TOOLKIT_SCROLL_BARS XIM ZLIB

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

Major mode: TSX

Minor modes in effect:
  rainbow-delimiters-mode: t
  electric-pair-mode: t
  guru-mode: t
  subword-mode: t
  eglot--managed-mode: t
  flymake-mode: t
  popper-echo-mode: t
  popper-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  joro-mode: t
  doom-modeline-mode: t
  minions-mode: t
  override-global-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  global-hl-todo-mode: t
  hl-todo-mode: t
  which-function-mode: t
  global-company-mode: t
  company-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-descbinds-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  ivy-mode: t
  editorconfig-mode: t
  winner-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-anzu-mode: t
  anzu-mode: t
  projectile-mode: t
  volatile-highlights-mode: t
  global-hl-line-mode: t
  super-save-mode: t
  windmove-mode: t
  recentf-mode: t
  savehist-mode: t
  save-place-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  prelude-mode: t
  shell-dirtrack-mode: t
  which-key-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mac-mouse-wheel-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
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/gdanov/.emacs.d/elpa/cmake-mode-20221130.1357/cmake-mode hides /usr/local/share/emacs/site-lisp/cmake/cmake-mode
/Users/gdanov/.emacs.d/elpa/transient-20221119.1503/transient hides /usr/local/Cellar/emacs-mac/emacs-28.2-mac-9.1/share/emacs/28.2/lisp/transient

Features:
(shadow sort mail-extr emacsbug sendmail typescript-mode
cc-mode-expansions smartparens-c cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs eieio-opt speedbar
ezimage dframe helm-command bug-reference helm-x-files elisp-slime-nav
rainbow-delimiters elec-pair guru-mode subword-mode-expansions cap-words
superword subword eglot array jsonrpc ert debug flymake-proc flymake
ffap tramp-archive tramp-gvfs dbus helm-for-files helm-bookmark
helm-adaptive helm-external helm-net codespaces
use-package-ensure-system-package system-packages use-package
use-package-delight use-package-diminish tramp-theme em-dirs esh-var
esh-mode poly-markdown smartparens-markdown markdown-mode polymode
poly-lock polymode-base polymode-weave polymode-export polymode-compat
polymode-methods polymode-core polymode-classes eieio-custom eieio-base
graphql-mode let-alist org-jira org-jira-sdk jiralib request soap-client
url-http url-auth url-gw nsm rng-xsd xsd-regexp xml org-clock
the-org-mode-expansions org-element avl-tree smartparens-org org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src
ob-comint org-pcomplete org-list org-faces org-entities noutline outline
org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol
org-keys oc org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs git-link popper-echo popper magit-bookmark magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
git-commit log-edit message rmc puny rfc822 mml mml-sec epa epg rfc6068
epg-config gnus-util rmail rmail-loaddefs mailabbrev mail-utils
gmm-utils mailheader add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
magit-git magit-base magit-section crm compat-27 compat-26 prettier-js
web-mode-expansions web-mode disp-table smart-shift indent-tools
yafolding hydra lv indent-tools-indentation-of highlight-indentation
helm-cider-history helm-cider helm-cider-spec helm-cider-repl
helm-cider-cheatsheet helm-cider-util cider-cheatsheet cider cider-debug
cider-browse-ns cider-mode cider-find cider-inspector cider-completion
cider-profile cider-eval cider-jar arc-mode archive-mode
cider-repl-history pulse cider-repl cider-resolve cider-test
cider-overlays cider-stacktrace cider-doc cider-browse-spec
cider-clojuredocs cider-eldoc cider-client cider-common cider-connection
cider-util cider-popup sesman-browser nrepl-client nrepl-dict spinner
clojure-mode-expansions smartparens-clojure sesman clojure-mode align
parseedn parseclj-parser parseclj-lex parseclj-alist posframe
doom-modeline doom-modeline-segments doom-modeline-env
doom-modeline-core all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons shrink-path f f-shortdoc shortdoc s minions
doom-themes-ext-org doom-themes-ext-treemacs doom-themes-ext-neotree
doom-themes-ext-visual-bell face-remap doom-one-theme doom-themes
doom-themes-base nlinum linum helm-ring helm-ls-git derived vc-git
helm-ag helm-xref use-package-bind-key bind-key rainbow-mode
quelpa-use-package quelpa mm-decode mm-bodies mm-encode help-fns
radix-tree use-package-ensure use-package-core prelude-modules
prelude-xml nxml-mode-expansions rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap html-mode-expansions smartparens-html
sgml-mode facemenu dom nxml-util nxml-enc xmltok prelude-shell sh-script
smie executable prelude-emacs-lisp prelude-lisp prelude-programming
flycheck hl-todo compat compat-macs which-func prelude-css
prelude-company company-oddmuse company-keywords company-etags
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company prelude-helm-everywhere helm-mode
helm-misc helm-descbinds helm-eshell helm-elisp helm-eval edebug
backtrace find-func helm-info prelude-helm helm-projectile helm-files
image-dired image-mode exif helm-tags helm-buffers helm-occur helm-grep
helm-regexp helm-locate helm-types helm-imenu helm-utils helm-help helm
helm-global-bindings helm-easymenu helm-core async-bytecomp helm-source
helm-multi-match helm-lib async helm-config prelude-ivy two-column ivy
ivy-faces ivy-overlay colir color prelude-macos exec-path-from-shell
prelude-global-keybindings warnings prelude-editor editorconfig
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
operate-on-number calc-bin calc-ext calc calc-loaddefs calc-macs diff-hl
smartrep log-view pcvs-util vc-dir ewoc vc vc-dispatcher diff-mode
winner undo-tree diff queue eshell esh-cmd esh-ext esh-opt esh-proc
esh-io esh-arg esh-module esh-groups esh-util re-builder whitespace
tabify browse-kill-ring midnight ediff ediff-merg ediff-mult ediff-wind
ediff-diff ediff-help ediff-init ediff-util dired-x anzu avy tramp-sh
projectile skeleton ibuf-macs find-dired dired dired-loaddefs lisp-mnt
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr grep
compile ibuf-ext ibuffer ibuffer-loaddefs bookmark text-property-search
pp expand-region text-mode-expansions er-basic-expansions
expand-region-core expand-region-custom flyspell ispell rect etags
fileloop generator xref project volatile-highlights hl-line super-save
windmove recentf tree-widget wid-edit savehist saveplace diminish
smartparens-config smartparens-text smartparens advice dash autorevert
filenotify delsel prelude-mode easy-mmode crux docker-tramp tramp-cache
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
shell pcomplete comint ansi-color ring parse-time iso8601 time-date
ls-lisp format-spec thingatpt imenu-anywhere imenu pcase jka-compr
prelude-core epl prelude-ui which-key prelude-custom prelude-packages
cl-extra help-mode finder-inf rx info edmacro kmacro package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/mac-win mac-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer 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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads kqueue mac
multi-tty make-network-process emacs)

Memory information:
((conses 16 1024998 582937)
 (symbols 48 64969 19)
 (strings 32 287822 163197)
 (string-bytes 1 9937920)
 (vectors 16 113430)
 (vector-slots 8 2200185 552812)
 (floats 8 1234 2058)
 (intervals 56 14261 3055)
 (buffers 992 43))

bug#60534: 28.2; Forbidden reentrant call of Tramp

[Michael Albinus]

Georgi Danov <georgi.danov@gmail.com> writes:

Hi Georgi,

> As discussed in github issue
> https://github.com/joaotavora/eglot/issues/859# eglot over tramp throws
> "reentrant call" error. This is sympthom of underlying design issue -
>  aux libraries use files without being aware of the tramp conection, the
>  connection itself has no concurrency control, pooling or other
>  multi-user features and without that guard error different tramp clients
>  corrupt each other's communication with the language server.

Yes. This is a long standing problem in Tramp I have no solution
yet. Likely we need threading in Tramp for this, but this causes other
problems.

For the time being I merge this with bug#49954, which points to the same
problem (although with different symptoms).

Best regards, Michael.