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

[Alan D. Salewski]

Hello All,

I am using tramp version 2.0.25 with GNU Emacs 21.2 on a GNU/Linux
system to edit files on a remote Solaris 2.8 system (using the `ssh'
connection method).

Most of the time this works fine, but every once in a while visiting a
remote file makes my emacs crash. After some experimentation, I noticed
that this was most likely to happen when visiting particular files
(though it didn't happen with /every/ visit to the file), and that those
particular files were somewhat large in comparison with most of the
remote files I edit. The file I noticed this behavior on the most is
currently 168298 bytes, and the file I noticed this behavior with
(several times) today is 96310 bytes. Most of the remote files I need to
edit are around 45000 bytes.

In a (perhaps silly) attempt to remove variables from the mix prior to
debugging, I have downloaded and compiled the emacs and tramp sources
from savannah; this allowed me to compile in debugging info into my
emacs binary and remove questions about changes that may have been
introduced by package maintainers for my GNU/Linux distribution. I still
get the same behavior.

The backtrace from gdb indicated that this was occurring in the emacs
garbage collection routines (though I profess my complete ignorance of
emacs internals (and, for that matter,  near complete ignorance of
elisp, as you'll see further on below)). In case this info would make
the problem obvious to any of the experts on this list, here's the first
chunk of the gdb output:

    Starting program: /usr/local/src/emacs21-21.2/src/emacs -geometry 80x40+0+0
    
    Breakpoint 1, abort () at emacs.c:387
    387       kill (getpid (), SIGABRT);
    (gdb) bt 10
    #0  abort () at emacs.c:387
    #1  0x08168a35 in mark_object (argptr=0x8e41c2c) at alloc.c:4705
    #2  0x08168a69 in mark_object (argptr=0x8e41c24) at alloc.c:4721
    #3  0x08168a69 in mark_object (argptr=0xbffe82e4) at alloc.c:4721
    #4  0x0816a2bc in mark_maybe_pointer (p=0x8e41c14) at alloc.c:3502
    #5  0x0816728e in mark_memory (start=0xbffe8350, end=0xbfffec78) at 
alloc.c:3552
    #6  0x08167307 in mark_stack () at alloc.c:3763
    #7  0x08167a38 in Fgarbage_collect () at alloc.c:4096
    #8  0x08181869 in Ffuncall (nargs=3, args=0xbffe8558) at eval.c:2599
    #9  0x08181602 in run_hook_list_with_args (funlist=1482699364, nargs=3, 
args=0xbffe8558) at eval.c:2382


I barked up that tree for a short while but thought I might be able to
glean some more immediately useful (to me) information by checking out
the lisp that was triggering the error:

    (gdb) xbacktrace
    0x8207608 "accept-process-output"
    0x870a504 "tramp-wait-for-output"
    0x8709c38 "tramp-send-command-and-check"
    0x8711068 "tramp-barf-unless-okay"
    0x87093e0 "tramp-handle-file-local-copy"
    0x8709404 "tramp-handle-insert-file-contents"
    0x82004c4 "apply"
    0x8202758 "byte-code"
    0x87239dc "tramp-file-name-handler"
    0x8204ca0 "insert-file-contents"
    0x8234a10 "find-file-noselect-1"
    0x82338ac "find-file-noselect"
    0x821f6f4 "find-file"
    0x8202804 "call-interactively"

Armed with that, I went rummaging around in tramp.el looking up
unfamiliar functions as I went along. One such function was
`accept-process-output', which is called like so in various places:

    (accept-process-output proc 1)

The documentation for that function tells me that the '1' in the above
call is a timeout in seconds, and that the function will return nil if
no output has been received before the timeout.

Though I have not really looked much deeper than this, I did do some
experimenting. After a while, I came up with the following to increase
the timeout value in serveral places:

    82a83
    > (require 'time-date)   ; in lisp/gnus/time-date.el in emacs sources, for 
'subtract-time'
    4452c4453
    <       (accept-process-output p 1)
    ---
    >       (accept-process-output p 10)
    5527c5528
    <                    (accept-process-output proc 1)
    ---
    >                    (accept-process-output proc 10)
    5533c5534
    <                (accept-process-output proc 1)
    ---
    >                (accept-process-output proc 10)

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.

Thanks,
-Al

-- 
a l a n   d.   s a l e w s k i             address@hidden
--------------------------------------------------------------------
We have orchistrated a phenomenally broad-based interoperable API.
--------------------------------------------------------------------
Generated from WWW Marketing Phrase gizmo:   www.lyra.org/phrase.cgi

pgpuzZ_ifMKKZ.pgp
Description: PGP signature