From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp" Date: Tue, 10 Aug 2021 15:52:47 +0200 Message-ID: <875ywdquds.fsf@gmx.de> References: <875ywf9ea7.fsf@secretsauce.net> <871r72ssqi.fsf@gmx.de> <874kby7wn5.fsf@secretsauce.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29214"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 49954@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 10 15:54:24 2021 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 1mDSD2-0007Ei-PE for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 15:54:24 +0200 Original-Received: from localhost ([::1]:34250 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDSCw-0008Bh-EP for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 09:54:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45752) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDSCg-00086w-Mh for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 09:54:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47257) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDSCg-0002Xw-GN for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 09:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mDSCg-00079Q-Fx for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 09:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Aug 2021 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49954 X-GNU-PR-Package: emacs Original-Received: via spool by 49954-submit@debbugs.gnu.org id=B49954.162860358327423 (code B ref 49954); Tue, 10 Aug 2021 13:54:02 +0000 Original-Received: (at 49954) by debbugs.gnu.org; 10 Aug 2021 13:53:03 +0000 Original-Received: from localhost ([127.0.0.1]:58803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDSBj-00078E-B6 for submit@debbugs.gnu.org; Tue, 10 Aug 2021 09:53:03 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:53241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDSBe-00077f-Rt for 49954@debbugs.gnu.org; Tue, 10 Aug 2021 09:53:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1628603569; bh=mQvZ/B2LNuDrn5RD3w9NN+JmHJizSYxGW1iwtDHGTpg=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Fxqkcgjn15gtjR3bpghEl+PNDHnHMMFXX0WAH2A5bsUTQoxdVIVQQ2MUv1JAdZ0Sd r9cVl/5Ic5PMGyFF4IG9MBooaQVLG4DMbdGEgf7u4ZkIYCf6AZ2XLQREDFiYERA298 iHFZTaY0nQ+y4CY8e6tBAo5pyPSA3DipnCxrJrIQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([213.220.147.198]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M9Wuq-1mAAOT1Ri8-005d0C; Tue, 10 Aug 2021 15:52:49 +0200 In-Reply-To: <874kby7wn5.fsf@secretsauce.net> (Dima Kogan's message of "Mon, 09 Aug 2021 21:26:38 -0700") X-Provags-ID: V03:K1:ipxtwv8ivUWckEwWuSq0agHSl7BWCI0LlEdy5zB8kjw4RLO69C7 07rNKA+m2VYCOtMXrntHFC8f9O1TBpuZFQksXJWrh0c8K2MQdVxek81gUPqVPGXD0nWYgsQ h4qo31SUL7Et0V849MjOQexdrJgDTF4wMQzxCjMF2ZglPrkNq3jOlQwetyqCjYJ/hUsUkkU 9PVO+i6+vQet0a73Agomg== X-UI-Out-Filterresults: notjunk:1;V03:K0:2Z3Sib9qaPc=:3skVxbhMHHaAQalLL2n76o QiTamzz+5MZIt0zmQ44U2w6/siNHVG8m5+beiVuXiQDYgIIEM3PQxXgjgfgIlCO++ZzPtw+wD bVMNOfsDyvum+MY2zEdn848/SdO+TH5GB3ZvCiYLkW9LNkRlv7t50HOE1aVwryYQw2zFkhYb4 ayPPnQM+Lpj+NFxWcg4EAqURZi0UE0CTPpc8jobx1jYvre/GuY0MUePK3VoqVv/TD7vJLl5XW wKWqubodM7l9ZjFEM+LRNEazTsiVUL1eR6PgC14m47y5DYfnGxfUmqKtFzsvTSo4kaFgsLtjk ZJA+fd04deyT+CQ8C76+ZuemC8d29FlcEP851a4sl3ZBqC1B6SEKFX1MHv9C27uUOVN1AunNy CVJNB/CbiwnQN670rvEHNg5bmh8qKoHwVmHjJe4V9TVqv3PT3xUss0yRlHR4EzVzwNK4kvBg1 hmEDejdmGLkoi41SWRCOco7UUvm6/ZELohVK7MQUXv6ZYEokighHfjlvl43p1wLdw9JghXzMy T5jPlPJNrVIF5fY3gXuVCGuahf1SV2xEfgDpbCUWlplBdb2Htf7Z8MH7SKTDmel4cr7iKWAJ/ W/i+Rv2nGeb1iSpJ3zL29jDzmvNHVCpKanf3+56SI7X+ibBtVApaRbPCn1sqDggcz5VLAZ6aN SNXAB8KRFBDI8SQOP+inv26As4HDR/oq4BGk3VJ1mJwNQsr/FEPEwVwC2+5B17eBZmnfxZOsR 6cvmyRsSqZbkPxCWpMI0rHIM7qOojIE579eACBT2/3yifP+Rgcp2P/rAuwjiywAvU59fVwUc 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" Xref: news.gmane.io gmane.emacs.bugs:211496 Archived-At: Dima Kogan 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.