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-".

Rejection

Answer 1

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.

Bennink

Of course not. Wish SO had a 'diff' utility while editing, I wanted to see where I mussed up. – Bennink

You had debug-on-errot. If you click on the link next to edited (e.g. '5 hours ago') above my gravatar, you can see the diff. Or do you mean something different? – Concussion

I tried this and it didn't work: I turned the value down to five and had debug-on-error T, but emacs did not drop me into the debugger: instead it just printed the usual error message. This happened where the error is in an auto-indenting function, could that be interfering with debug-on-error? – Ammoniac

I bumped into this (also in python editing). Emacs didn't want to indent things I had written. It seemed like a perfectly normal file, and exhibited the same problem on a close-reload cycle. All I had was an import, a function def (which it wouldn't indent after) and some pseudocode comments detailing what I was planning on writing. Seems like a subtle bug in python mode or the associated handlers. I can't seem to reproduce it now . . . so it may remain mysterious. After c/p rearranging the comments it started working. Weird eh? – Twilatwilight

@Twilatwilight FWIW, this type of bug is till present in python mode, 5 years after the original report and 2 years after the last comment. I'm getting py-end-of-statement: Variable binding depth exceeds max-specpdl-size This is exactly the kind of rathole I should be avoiding, but it's very tempting to try to track this down. – Blackmore

My suspicion (i switched to subl a year back now) is that it was related to some sort of caching it does on the python parsing so it doesn't have to reparse the file on each keystroke or some such. I never dug past that, and I sure don't plan to! – Twilatwilight

Answer 2

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.

Thoreau

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.

Augustin