[more info] tramp (2.0.25); able to make emacs crash

[Alan D. Salewski]

[Replying to my own message to share new info.]

On Thu, Nov 21, 2002 at 12:27:25PM -0500, Alan D. Salewski spake thus:
> 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.

I suspect I may be stumbling over a garbage collection bug in emacs, but
it just happens that the only sequence of events that I've been able to
use to reproduce the behavior involves tramp (probably because it is one
of the emacs modules I use the most).

I've evolved a test case that triggers the crash most of the time (at
least one in three tries, in my experience). Perhaps somebody here could
try to reproduce this to verify my findings?

On the remote machine, I create a rather deep directory structure that
looks like this:

    /space/download/ads/tmp/some_2.2_long/path/name/foo/bar/baz/quux/

It seems that I am able to trigger the crash more easily when the remote
directory structure is deeper.

I create a test file on the remote host using the following script:

    #!/usr/bin/perl -w
    #junk.pl
        use strict;
        for (1..12500) {
            print STDOUT "JUNK" x 20;
            print STDOUT "\n";
        }

    $ ./junk.pl > big_test.txt 

Then I attempt to visit the file in emacs using the 'ssh' connection
method. I'm using a very minimal emacs environment to run the test; I
created a ~/breakage/.emacs file to use for the test that looks like
this:

    (add-to-list 'load-path "~/breakage/src/tramp-2.0.25/lisp/")

    (require 'tramp)

    (setq tramp-varbose 10)

    (setenv "TR" 
"/ssh:address@hidden:/space/download/ads/tmp/some_2.2_long/path/name/foo/bar/baz/quux/big_test.txt")

This simply loads an unmunged, byte-compiled version of tramp from my
testing installation directory (and the "TR" definition keeps my fingers
from falling off while running all of these tests ;-)

I start up emacs from within gdb loading only the above config file:

    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i386-linux"...
    DISPLAY = :0.0
    TERM = xterm
    Breakpoint 1 at 0x810684a: file emacs.c, line 387.
    Breakpoint 2 at 0x80e0c3d: file xterm.c, line 12018.
    (gdb) run
    Starting program: /usr/local/src/breakage/emacs-21.2-21.2.orig/src/emacs 
--no-init-file --no-site-file -l /home/al/breakage/.emacs -geometry 120x60+0+0

I then do C-x C-f to visit the remote file, and watch the messages flash
in the mini-buffer until everything goes dark. The last message
displayed in the mini-buffer is usually

    tramp: Encoding remote file [...]

The backtrace is the same as before. Curiously, I am not able to cause
the crash to occur when running with the non-byte-compiled lisp files.
If I do a 'make clean' in my tramp source directory and restart emacs, I
cannot seem to make it crash when visiting the remote file. Does this
make any sense?

-Al

-- 
a l a n   d.   s a l e w s k i             address@hidden
--------------------------------------------------------------------
   We have launched a completely dynamic secure authoring tool.
--------------------------------------------------------------------
Generated from WWW Marketing Phrase gizmo:   www.lyra.org/phrase.cgi

pgpqVy2PRIifO.pgp
Description: PGP signature