Re: debugging "Lisp nesting exceeds max-lisp-eval-depth" error?

[Chris Moore]

I found a way of reproducing the problem, so I was able to get a
backtrace in the lisp debugger before the depth got too great:

Debugger entered--entering a function:
* tramp-file-name-handler(expand-file-name
"/home/chris/emacs/tramp.elc.gz" "/address@hidden:/home/moore_cm/")
[...]
* tramp-file-name-handler(expand-file-name
"/home/chris/emacs/tramp.elc.gz" "/address@hidden:/home/moore_cm/")
* tramp-file-name-handler(expand-file-name
"/home/chris/emacs/tramp.elc.gz" "/address@hidden:/home/moore_cm/")
* expand-file-name("/home/chris/emacs/tramp.elc.gz" nil)
* apply(expand-file-name ("/home/chris/emacs/tramp.elc.gz" nil))
* jka-compr-run-real-handler(expand-file-name
("/home/chris/emacs/tramp.elc.gz" nil))
* jka-compr-handler(expand-file-name "/home/chris/emacs/tramp.elc.gz" nil)
* tramp-file-name-handler(expand-file-name "/"
"/address@hidden:/home/moore_cm/")
* expand-file-name("/")
* dired-noselect("/" nil)
* byte-code("ÂÃ        \"!‡" [dirname switches switch-to-buffer 
dired-noselect] 4)
* dired("/" nil)
  call-interactively(dired)

The 'tramp' that is loaded is this one, from my CVS Emacs working directory:

  -rw-r--r--  1 chris chris 306138 Mar 29 02:51 tramp.el
  -rw-r--r--  1 chris chris 241289 Mar 29 03:31 tramp.elc

 Note that although /home/chris/emacs/ exists, and is the first entry
in my 'load-path', there are no files in there with 'tramp' in their
name at all.  The jka-compr I'm using is also coming from my CVS Emacs
working directory:

  -rw-r--r--   1 chris chris   31670 Mar 29 02:50 jka-compr.el
  -rw-r--r--   1 chris chris   21581 Mar 29 03:29 jka-compr.elc

This was happening with a huge .emacs that I've built up over the
years.  I've been cutting it down all morning, and now I have a 2 line
.emacs which causes a similar problem.  Can you reproduce this?

Put this in .emacs:

----------------------------------------------
(setq default-directory "/localhost:/usr/")
(dired "/")
----------------------------------------------

and then start Emacs ("emacs -nw --no-site-file").  I see the
*Messages* buffer taking up the whole display for about 1 second
before the usual Emacs logo appears.  The *Messages* buffer contains
the following: :

----------------------------------------------
(/home/chris/programs/emacs/src/emacs --no-site-file)
Loading dired...
Loading regexp-opt...done
Loading dired...done
Loading tramp... [4 times]


An error has occurred while loading `/home/chris/.emacs':

error: Recursive load, /home/chris/programs/emacs/lisp/net/tramp.elc,
/home/chris/programs/emacs/lisp/shell.elc,
/home/chris/programs/emacs/lisp/net/tramp.elc,
/home/chris/programs/emacs/lisp/shell.elc,
/home/chris/programs/emacs/lisp/net/tramp.elc,
/home/chris/programs/emacs/lisp/shell.elc,
/home/chris/programs/emacs/lisp/net/tramp.elc,
/home/chris/programs/emacs/lisp/shell.elc,
/home/chris/programs/emacs/lisp/net/tramp.elc, /home/chris/.emacs

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the `--debug-init' option to view a complete error backtrace.
----------------------------------------------

I'm not sure if this is the same bug or not, but it's *a* bug at
least, wouldn't you agree?

Chris.

On Apr 6, 2005 4:03 AM, Richard Stallman <address@hidden> wrote:
> If things are that messed up, you probably need to do your debugging
> in GDB.  You could put a GDB breakpoint at lines like this in eval.c:
> 
>         error ("Lisp nesting exceeds max-lisp-eval-depth");
> 
> (I think there are two such lines.)
>