Tracking down max-specpdl-size errors in emacs

Question

I've been randomly getting the following error in emacs:

Variable binding depth exceeds max-specpdl-size

...and I've been getting it at very random moments. After researching this, it seems as though some elisp somewhere is recursing too deeply. Are there any strategies for tracking this down? I'm totally at a loss as far as what is actually causing this.

I've gotten some errors indicating something along the lines of infinite recursion with ropemacs (but these are usually Python errors). Could something be misconfigured with ropemacs?

Update: Interestingly enough, I've found that I always get this error if I do a "C-h a" for "speedbar" but not for "rope-".

Answer 1

For me too it did not work. I found with C-h+v that actually max-specpdl-size was not changed to 5 at all by the setq. I then tried to set it interactively with M-x set-variable. That too did not change its value. Finally I managed to set it with M-x customize-variable.

Btw, on my system max-specpdl-size was 140 and thus to small. I had to increase it to 1000, not in order to get a backtrace and debug it, but to make it work.

Answer 2

To track the problem down, you can try this:

(setq max-specpdl-size 5)  ; default is 1000, reduce the backtrace level
(setq debug-on-error t)    ; now you should get a backtrace
C-h a ; in speedbar

You should get a backtrace upon the error, and at that point, you can track down the offending routine.

I'd also try loading emacs w/out your configuration file (emacs -q), to see if there's something in your .emacs that is affecting things. (I don't get the infinite loop using C-h a). And if it is your .emacs, then the best way I've found to track that down is either binary search (put an error (error "frog") or somesuch in the middle of your .emacs, load, test, if no problems, put the error at 3/4, otherwise at 1/4, repeat...), or manually evaluate your .emacs line by line (region by region), testing after each portion. Those settings should help.

Answer 3

The kind of bug still exists 10 years after the report, in XEmacs 21.4 (patch 24) "Standard C" [Lucid] (x86_64-linux-gnu, Mule). I get it from M-x vm (trying to read my e-mail, which I do many times every day).

Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
  signal(error ("Variable binding depth exceeds max-specpdl-size"))
  byte-code("..." [buf data kill-buffer signal] 3)
  find-file-noselect("/home/brech/mail/folders/INBOX")
  byte-code("..." [f full-startup access-method remote-spec buffer-file-coding-system folder string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
  ad-Orig-vm(nil nil nil)
  (setq ad-return-value (ad-Orig-vm folder read-only access-method))
  (let (ad-return-value) (if (and ... mail-archive-file-name folder ... ...) (setq read-only ...)) (setq ad-return-value (ad-Orig-vm folder read-only access-method)) ad-return-value)
  (lambda (&optional folder read-only access-method) "$ad-doc: vm$" (interactive (list nil current-prefix-arg)) (let (ad-return-value) (if ... ...) (setq ad-return-value ...) ad-return-value))(nil nil)
  call-interactively(vm)
  command-execute(vm t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

A crude work-around is quitting XEmacs and starting all over. Only quitting and re-starting vm does not help.