From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.devel Subject: Re: Fix to long-standing crashes in GC Date: Fri, 14 May 2004 22:48:14 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <86y8nuivld.fsf@slowfox.dyndns.org> References: <40A3BC23.8060000@math.ku.dk> <87brks5e94.fsf-monnier+emacs@gnu.org> <200405132216.i4DMG7G14599@raven.dms.auburn.edu> <87k6zfb5gs.fsf@emptyhost.emptydomain.de> <200405141453.i4EErEQ16894@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084570809 27537 80.91.224.253 (14 May 2004 21:40:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 May 2004 21:40:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 14 23:40:02 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOkPS-0007bS-00 for ; Fri, 14 May 2004 23:40:02 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOkPS-0000Xz-00 for ; Fri, 14 May 2004 23:40:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOjhK-000314-SU for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 16:54:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOje4-0002Hb-6H for emacs-devel@gnu.org; Fri, 14 May 2004 16:51:04 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOjbO-0001ea-Pk for emacs-devel@gnu.org; Fri, 14 May 2004 16:48:59 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOjbN-0001ds-U4 for emacs-devel@gnu.org; Fri, 14 May 2004 16:48:18 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BOjbN-0005TH-00 for ; Fri, 14 May 2004 22:48:17 +0200 Original-Received: from pd9e1e7fe.dip.t-dialin.net ([217.225.231.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 May 2004 22:48:17 +0200 Original-Received: from kai.grossjohann by pd9e1e7fe.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 May 2004 22:48:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 57 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9e1e7fe.dip.t-dialin.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) Cancel-Lock: sha1:z8Q/v9d9+HHy96zqV07wK6rfKdI= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23431 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23431 Luc Teirlinck writes: > Kai Grossjohann wrote: > > Please see the variable tramp-chunksize, try to set it to 500 to see > what happens, and also do what the docstring says. > > I executed the function in the tramp-chunksize docstring. Result: > > "Bytes sent: 1000 Bytes received: 1000" > > That seems to indicate that my system does not have the problem > referred to in the docstring. > > I set tramp-chunksize to 500. Still the same: > > tramp: Decoding remote file /ssh:raven.dms.auburn.edu:/home/teirllm/streams.texi with function base64-decode-region... > tramp-handle-file-local-copy: Invalid base64 data > > (Yanked from *Messages*.) > > Note that the error only occurs when using auto-revert-mode and when > there already is a remote file being visited (and hence > auto-reverted). This problem and the crash do not occur if > auto-reverting of remote files is disabled using the option I posted. Yeah, I guess it's two commands stepping on each other's toes: You say C-x C-f, which transfers base64 data across the wire. Auto-revert then gets triggered from a timer which just switches to the connection buffer and issues its own base64 data transfer. Now you get a happy mixture of base64 data from two different files, and the consequences are no good :-/ It's really amazing that nobody has noticed these problems up to now. Tramp is not *that* young... So I see two possible short-term kludges: - Disable auto-revert on remote files. - Have Tramp detect reentrant calls, and abort the call from the timer. (I'm hoping that auto-revert will try again after a while, if one revert fails.) I think the only sane long-term solution is to teach Tramp to use multiple connections, and to use a new connection for each timer function. However, opening a new connection might entail user interaction (for entering passwords), and I'm not sure that auto-revert mode is prepared for this. Actually, sane is the wrong word: it's the only solution where I have at least some idea how to implement it. My wetware is not up to David's suggestion, I'm afraid. Kai