Re: [long] tramp (2.0.25); able to make emacs crash, a clunky workaround, and request for guidance

[Kai Großjohann]

"Alan D. Salewski" <address@hidden> writes:

> These changes seem to have the effect I was looking for; that is, with
> these changes in place, I have not yet experienced an emacs crash.
>
> Now, I'm not recommending this as a change to tramp (I'm sure those
> values have been set at '1' for a reason). I am interested in learning
> more about what's going on there in the code, and would be grateful for
> any pointers on better ways to go about debugging/fixing this.

Quite fascinating.  Maybe increasing the timeout tenfold has
increased the breaking filesize tenfold, too?  ;-)  Just kidding...

Now, I'm pretty sure that it should be impossible for Lisp to cause
Emacs to crash.  It's the Lisp interpreter's job to prevent that.  So
the question is can you make Emacs barf without the large Tramp thing
going on.  But that requires a lot of work.  Hm.  I've never seen a
crash with Tramp, but I shall try to use it with large files to see
if it crashes there.

Could you create some large files with meaningless content to see if
it is more likely for Emacs to crash with very large files?

Does it depend on the network connectivity to the remote host?  (Maybe
a host that you have a fast connection to needs larger files, or one
with a slow connection needs larger files.)  Does it depend on any
other characteristic of the remote host?

And when does Emacs crash?  After hitting C-x C-f and the filename
and then RET?  Or during saving?

You produced a very nice bug report, the reason for these many
questions is that I don't really grok what's going on...

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)