Re: Fix to long-standing crashes in GC

[Kai Grossjohann <kai.grossjohann@gmx.net>]

Luc Teirlinck <teirllm@dms.auburn.edu> 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