GNU bug report logs - #61350
Eglot over Tramp freezes with large project

Previous Next

Full log

View this message in rfc822 format

From: Thomas Koch <thomas <at> koch.ro>
To: Michael Albinus <michael.albinus <at> gmx.de>, João Távora <joaotavora <at> gmail.com>
Cc: 61350 <at> debbugs.gnu.org
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Sun, 5 Mar 2023 13:45:49 +0200 (EET)

Thanks Michael for digging! This is exactly what I also think happens.

However my conclusion is different. I consider the root-cause to be the use of JUST-THIS-ONE in tramps call to accept-process-output. Please check my comment to bug 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145

Applying a workaround (adding extra code to surpress ControlMaster with a newly introduced hook) would increase the complexity and thus brittleness. I believe the right thing to do is remove JUST-THIS-ONE in Tramp and fix find-name-dired and any other place that's broken.

As a practical roadmap you could add an option to Tramp to disable JUST-THIS-ONE and recommend its use. Later the options default could be toggled. Eventually the option can go away.

Eglot could emit a warning if it sees the above tramp option not being used. (... could lead to Emacs hanging. Are you sure to continue (y/n)?)


> Michael Albinus <michael.albinus <at> gmx.de> hat am 05.03.2023 13:21 EET geschrieben:
> 
>  
> João Távora <joaotavora <at> gmail.com> writes:
> 
> Hi João,
> 
> >> Yes. But Tramp calls accept-process-output only, if it has send a
> >> command to the remote shell, and it expects something to be returned. At
> >> least the shell prompt.
> >
> > Yes.  Tramp is doing the right thing.  It really expects a response to
> > come.  And more often than not, it does.  But sometimes it doesn't, and
> > that's when we hang.
> 
> After digging further, I believe I understand now why it hangs. We have
> the following scenario:
> 
> - Both Eglot and Tramp use the same ssh connection with enabled ControlMaster.
> 
> - Eglot gets JSON output from the remote LSP server. In
>   jsonrpc--process-filter, this output is handled. It includes a call to
>   file-truename, which triggers Tramp to send a request in its own
>   process to the remote side.
> 
> - The remote side returns the answer for Tramp (shell output). However,
>   the ssh socket is still full of the jsonrpc process output, which
>   waits to be handled.
> 
> - So the socket is blocked. The jsonrpc output cannot be read, because
>   jsonrpc--process-filter waits for the result of file-truename. And the
>   Tramp process output cannot be handled, because it is stuck in the
>   socket after the jsonrpc output.
> 
> The proper solution is indeed to have two connections, and to refuse use
> of ControlMaster.
> 
> Surprisingly, this is not new to Tramp :-) But I've simply forgotten the
> case ...
> 
> See tramp-integration.el. There is a comment for bug#45518, a similar
> blocking in compile.el. And the solution is indeed to disable ssh
> ControlMaster. Tramp hooks into compilation-mode-hook, and sets
> tramp-use-ssh-controlmaster-options buffer-local to nil.
> 
> I'd like to apply the same solution for eglot.el. Unfortunately, there's
> no hook Tramp could use. I've played with eglot-server-initialized-hook,
> but this is applied too late.
> 
> So would you mind to add a hook to Eglot, which runs before calling
> make-process, but in the proper process buffer? When you've added it,
> I'll let Tramp hook into, and you don't need any longer the Tramp
> specific code in eglot.el.
> 
> In parallel, I'll extend tramp-use-ssh-controlmaster-options to accept a
> further value 'suppress', which overrides possible settings in ~/.ssh/config.
> 
> > João
> 
> Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.