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

[Alan D. Salewski]

On Wed, Nov 20, 2002 at 09:59:14PM +0100, Kai Gro?johann spake thus:
*snip* 
> 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?

I've byte compiled a pristine version of tramp v. 2.0.25, and created a
couple of testing files on the remote host. The "large" testing file is
just over 1M in size, and contains junk strings in 80 character lines;
the "small" test file is simply several lines of text. On my first
attempt I put the files in a directory that looks like this:

    /space/download/ads/tmp/

I was able to open both of the files. I then moved the files into a
deeper directory structure (which more closely resembles the "real"
directory structure I work in on the remote host):

    /space/download/ads/tmp/some_2.2_long/path/name/

and tried to open the large testing file.  This time emacs bombed out on
me with the same backtrace as before:

    Breakpoint 1, abort () at emacs.c:387
    387       kill (getpid (), SIGABRT);
    (gdb) backtrace 10
    #0  abort () at emacs.c:387
    #1  0x081689c5 in mark_object (argptr=0x887220c) at alloc.c:4705
    #2  0x081689f9 in mark_object (argptr=0xbffe8284) at alloc.c:4721
    #3  0x08169f84 in mark_maybe_object (obj=1485251084) at alloc.c:3394
    #4  0x081671ee in mark_memory (start=0xbffe82e0, end=0xbfffec08) at 
alloc.c:3531
    #5  0x08167297 in mark_stack () at alloc.c:3763
    #6  0x081679c8 in Fgarbage_collect () at alloc.c:4096
    #7  0x081817f9 in Ffuncall (nargs=3, args=0xbffe84e8) at eval.c:2599
    #8  0x08181592 in run_hook_list_with_args (funlist=1483195772, nargs=3, 
args=0xbffe84e8) at eval.c:2382
    #9  0x08132ad8 in signal_before_change (start_int=206518, end_int=206518, 
preserve_ptr=0x0) at insdel.c:1930
    (More stack frames follow...)
    (gdb) xbacktrace 10
    0x8207560 "accept-process-output"
    0x8733828 "tramp-wait-for-output"
    0x8732f5c "tramp-send-command-and-check"
    0x873451c "tramp-barf-unless-okay"
    0x8730878 "tramp-handle-file-local-copy"
    0x873089c "tramp-handle-insert-file-contents"
    0x8200444 "apply"
    0x82026d8 "byte-code"
    0x873d3b4 "tramp-file-name-handler"
    0x8204bf8 "insert-file-contents"
    0x8234530 "find-file-noselect-1"
    0x8233454 "find-file-noselect"
    0x821f610 "find-file"
    0x8202784 "call-interactively"
    (gdb)

I then restarted emacs and tried again to open the files (in the deeper
directory). This time it succeeded. So I killed both buffers, and
attempted to visit the larger file again. This time it bombed out (same
as above).

<emacs_restart/>
I opened the smaller test file in the deeper directory. Worked. Killed
buffer. Repeat 20 times, worked every time.

I opened the larger test file in the deeper directory. Worked. Killed
buffer. Repeat 5 tmes successfully. On the 6th iteration, I got an error
in the mini-buffer indicating "Invalid base64 data". I tried to visit
the file again, and this time it bombed out (same as above).

<emacs_restart/>
*This time I'm trying to rule out the effect the deep directory
structure may or may not have on this whole thing*
I opened the larger test file in the more shallow directory. Worked.
Killed buffer. Repeat 10 times successfully. On the 11th iteration, I
got the "Invalid base64 data" error message. I tried to visit visit the
file again and succeeded (12th try). Tries 13 through 26 all succeeded,
too.

So at this point it looks to me as though whatever is going wrong is
either directly or indirectly influenced by a) the size of the remote
file and b) the depth of the directory on the remote host.

I'll try to narrow this down further, but this is where I'm at at the
moment (hunting in the dark...)
 
> 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?

The connection to the remote machine is through switched fast ethernet.
The remote machine is under-powered and shared by a team of developers,
so it is subject to occasional CPU-cycle competitions; however, I've
noticed the behavior even when I was the only user logged in and the
machine was under very light load. As for other characteristics, I can't
think of anything that would be troublesome.

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

Most times I notice it some time after hitting C-x C-f, but I have also
noticed it when checking what I consider "the problematic files" back
into CVS through the vc interface. I do C-x C-q to get the *VC-log*
buffer, enter my messages, and then do C-c C-c to finalize the commit.
I've had emacs bomb out after doing the C-c C-c, but the commit works.

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

Thanks :-)  I'm more than willing to provide as much info as I can, and
run as many tests as I can.

-Al

-- 
a l a n   d.   s a l e w s k i             address@hidden
--------------------------------------------------------------------
    We have written a wonderfully market-leading interoperable
                             offering.
--------------------------------------------------------------------
Generated from WWW Marketing Phrase gizmo:   www.lyra.org/phrase.cgi

pgp7Bh3msKuMy.pgp
Description: PGP signature