[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix to long-standing crashes in GC
From: |
Kai Grossjohann |
Subject: |
Re: Fix to long-standing crashes in GC |
Date: |
Fri, 14 May 2004 22:48:14 +0200 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) |
Luc Teirlinck <address@hidden> 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
- Re: Fix to long-standing crashes in GC, (continued)
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/13
- Re: Fix to long-standing crashes in GC, Lars Hansen, 2004/05/13
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/13
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/13
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/13
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/13
- Re: Fix to long-standing crashes in GC, Kai Grossjohann, 2004/05/14
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/14
- Re: Fix to long-standing crashes in GC,
Kai Grossjohann <=
- Re: Fix to long-standing crashes in GC, Kai Grossjohann, 2004/05/16
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/14
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/14
Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/14
- Re: Fix to long-standing crashes in GC, Lars Hansen, 2004/05/23
- Re: Fix to long-standing crashes in GC, Eli Zaretskii, 2004/05/23
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/23
- Re: Fix to long-standing crashes in GC, Lars Hansen, 2004/05/23
- Re: Fix to long-standing crashes in GC, Eli Zaretskii, 2004/05/24
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/24