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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: João Távora <joaotavora <at> gmail.com>
Cc: Thomas Koch <thomas <at> koch.ro>, monnier <at> iro.umontreal.ca, 61350 <at> debbugs.gnu.org
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Tue, 14 Mar 2023 16:42:44 +0100

João Távora <joaotavora <at> gmail.com> writes:

Hi João,

>> I will investigate. IMHO, this is the final indication that we shouldn't
>> allow a nil JUST-THIS-ONE in accept-process-output.
>
> I don't see this failure as an indication of that, at all!!
>
> First, you didn't do that -- put nil in JUST-THIS-ONE --  did you?
> At most this means that you are doing more or less the same
> as setting JUST-THIS-ONE to nil, but in a much more convoluted
> way, so that you may as well start setting JUST-THIS-ONE to nil...

It is an indication, that, if some processes accept output at the same
time, and this output runs through process filters, anything can happen.

No, I didn't set JUST-THIS-ONE to nil. I just allow related processes,
belonging to the same Tramp connection, to do so. This is a case we have
under our control. When JUSt_THIS-ONE is set to nil, the same could
happen to any arbitrary process running randomly in concurrency to a
Tramp process, and this we wouldn't have under our control.

> ...and bite the bullet, continuing this analysis.  We're making
> progress...

Sure, I'll do. Coincidently, the author of filenotify.el and
filenotify-tests.el is well known to us, I'll contact him :-)

> For me, this means that those auto-revert and symlinks-remote tests,
> whatever they are, must be investigated. It's good that you have these
> tests! Do they fail in all Emacsen or just some? Always/sometimes?
> Can I reproduce this here?

This happens with Emacs master (which runs on EMBA). And I could
reproduce it locally, with slightly modified error messages, by

--8<---------------cut here---------------start------------->8---
# make -C test filenotify-tests
--8<---------------cut here---------------end--------------->8---

> After we get a consistent failure, we should ask ourselves what exactly
> is the reentrancy in question here. Perhaps you already have a conjecture
> of the chain of events that leads to it.

Yes, I have. Contacting the author ...

> 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.