From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thomas Koch Newsgroups: gmane.emacs.bugs Subject: bug#61350: Eglot over Tramp freezes with large project Date: Tue, 28 Feb 2023 19:55:17 +0200 (EET) Message-ID: <1458446553.50372.1677606917251@office.mailbox.org> References: <87y1ootw2t.fsf@gmail.com> <69968923.705640.1677163650760@office.mailbox.org> <87a613f0b7.fsf@gmx.de> <87r0udvmzr.fsf@gmx.de> <878rglxrzm.fsf@gmail.com> <87cz5wmjbx.fsf@gmx.de> <87h6v8f7u9.fsf@gmail.com> <87o7pflfcd.fsf@gmx.de> <87wn43e9ht.fsf@gmail.com> <874jr6oont.fsf@gmx.de> <87sfeqd4zi.fsf@gmail.com> <877cw1swjm.fsf@gmx.de> <87k0016dgo.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21757"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61350@debbugs.gnu.org To: Michael Albinus , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 28 18:56:32 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pX4DI-0005MW-2W for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Feb 2023 18:56:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pX4D5-0005O8-AP; Tue, 28 Feb 2023 12:56:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pX4Cz-0005Nm-Ja for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 12:56:14 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pX4Cp-0004fe-0V for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 12:56:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pX4Co-0007Ja-IA for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 12:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Koch Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Feb 2023 17:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61350 X-GNU-PR-Package: emacs Original-Received: via spool by 61350-submit@debbugs.gnu.org id=B61350.167760692928075 (code B ref 61350); Tue, 28 Feb 2023 17:56:02 +0000 Original-Received: (at 61350) by debbugs.gnu.org; 28 Feb 2023 17:55:29 +0000 Original-Received: from localhost ([127.0.0.1]:51954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX4CH-0007Ik-3O for submit@debbugs.gnu.org; Tue, 28 Feb 2023 12:55:29 -0500 Original-Received: from mout-p-201.mailbox.org ([80.241.56.171]:53776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX4CE-0007IT-Ay for 61350@debbugs.gnu.org; Tue, 28 Feb 2023 12:55:27 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4PR4lT69V0z9sjD; Tue, 28 Feb 2023 18:55:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=koch.ro; s=MBO0001; t=1677606918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qtdVgFz495+XmdbySukC6VVAM8G8i0SUXgyw8AgrjGQ=; b=ECrfTxQCdKGoeW3BEOC4IdTHf9cYp0e/0ZNkzVkFDdjt1wCOy7ybrAt9DmakzO3gvZs26V AEmFa16TDr4UVDk7yndnqx1XZxlcaXIHiQTKRAiV7tnqsa6MaQbnwW/7sCT75M9wzPHqZE ++RFYPQKDYMXKCZJHC9qkmWY3/KVjcO6DbapB9pNkfk0ocTVVeSoX4WebLemjMawRDkB1o ZFUcueJ2qvY/eAFjimNbl7XQxRa4v5KG8FA0QFEEB5rEHiTeu/bgbFRT1DG+8PLE6ergOy G9RQ8dnWHdj+hOWP51NW+1fbijkYRsiBIgdAaGkin7Pie5Sj/26StzFJSXRYHQ== In-Reply-To: <87k0016dgo.fsf@gmx.de> X-Priority: 3 Importance: Normal X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256999 Archived-At: Thank you both for being so constructively engaged in the bug I opened. I'll give Joao's patch a try tomorrow. (I'm too tired now.) However I don't see ControlMaster as the root cause at the moment. My current working theory is: 1. There is some buffer in SSH (or TCP) that gets filled by the language server sending data to eglot. 2. Tramp sends a command over SSH. 3. Tramp sets the JUST-THIS-ONE option of accept-process-output to t since https://debbugs.gnu.org/12145. 4. The response to 2. can not arrive due to the buffer being filled in 1. Tramp blocks the emacs main thread. I tested my theory by deleting (and thus disabling) the JUST-THIS-ONE argument in all calls to accept-process-output in tramp.el and tramp-sh.el. Eglot did not freeze anymore in two tests with two different systems (but the same jdtls binary on the same Debian version). In one test however I saw this in the message buffer: [jsonrpc] (warning) Invalid JSON: (control character 0xd 1 381 381) {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///home/thk/git/yacy_search_server/source/net/yacy/htroot/ConfigSearchBox.java","diagnostics":[{"range":{"start":{"line":35,"character":86},"end":{"line":35,"character":94}},"severity":3,"code":"1102","source":"Java","message":"At least one of the problems in category \u0027unuseContent-Length: 798 {"jsonrpc":"2.0","method":"textDocument/publ I already sent the above to Michael in an out-of-band thread (thanks for your patience!). I have a vague feeling, that Tramp could be improved with a work queue such that requests to tramp from notification or timer threads get blocked while another tramp command is still waiting for a reply. Additionally I understand that Joao has an idea to use markers controlled by Tramp. - I'm sorry that I can not (yet) contribute with putting both ideas into code. There are two statements in this bug thread that I don't yet understand and that might be worth more elaboration. I volunteer as a debugging rubber duck[1]. However if you both understand each other then never mind: [1] https://en.wikipedia.org/wiki/Rubber_duck_debugging Joao: "markers in the process buffer is what is used commonly" I understand that tramp sends only one command at a time per connection. Otherwise the reentrant error is thrown. The command result gets written to a connection-specific buffer. The output is parsed from point-min and the buffer content deleted after parsing and before sending the next command. So what should there be improved? Jsonrpc needs its own markers because N messages can arrive at any given time and the buffer can not be deleted after each message. Michael: "If another process has consumed the output, even if it is pushed into the correct buffer, Tramp doesn't know." What exact scenario should that be? Emacs writes the output (if there's no filter) in the correct buffer for the process. Tramp might call accept-process-output unnecessarily because the output is already in the buffer due to a accept-process-output call of some other code. But in this case Tramp will find the output there eventually, maybe after having waited until a timeout. This could be improved by checking for already present output before calling accept-process-output?