segfault after changing max-lisp-eval-depth and max-specpdl-size

segfault after changing max-lisp-eval-depth and max-specpdl-size

[Paul Stoeber]

In GNU Emacs 21.2.1 (powerpc-unknown-linux-gnu)
 of 2002-05-26 on xyz
configured using `configure  --prefix=/e --without-x'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Built without modification from
MD5:f4b58e5c2d923fc92495e0c2f167c5db URL:ftp://ftp.cs.tu-berlin.de/pub/gnu/emacs/emacs-21.2.tar.gz


I have this expression in my `*scratch*' buffer:

(progn
  (setq max-lisp-eval-depth 30000)
  (setq max-specpdl-size 30000)
  (defun seq (a b)
    "Return sequence of integers A, A+1, ..., B as a list."
    (if (> a b)
	()
      (cons a (seq (1+ a) b))))
  (length (seq 1 10000)))

I go to its last line and type C-e C-x C-e, and then it looks like this:

  (length (seq 1 10000)))Segmentation fault
q@xyz~$ 


The descriptions of `max-lisp-eval-depth' and `max-specpdl-size'
both say "You can customize this variable."

I have not found this problem in etc/PROBLEMS or info/efaq* .


I think it should be possible to put your functional programmer's hat on
by saying

  (setq max-lisp-eval-depth (setq max-specpdl-size 134217727))

or better still

  (setq have-lisp-limits nil) ; don't bother me



---

Avoid arbitrary limits on the length or number of _any_ data structure [...]
                -- GNU Coding Standards

Re: segfault after changing max-lisp-eval-depth and max-specpdl-size

[Richard Stallman]

It is not easy for Emacs to recover from a real stack overflow.
Part of the reason for these variables is so that it won't get one.

Re: segfault after changing max-lisp-eval-depth and max-specpdl-size

[Paul Stoeber]

On Tue, May 28, 2002 at 02:23:50PM -0600, Richard Stallman wrote:
> It is not easy for Emacs to recover from a real stack overflow.
> Part of the reason for these variables is so that it won't get one.

That means I'll have to use let/while/setq instead of recursion
in order to "Avoid arbitrary limits", which produces less
enjoyable code.

I hoped the Lisp interpreter would use my available memory to evaluate
expressions as far as possible, until ENOMEM, instead of bothering me
with oddities like `max-lisp-eval-depth' and `max-specpdl-size'.  But
for that it would need a hand-allocated stack instead of the C stack.
You probably don't want to change the implementation that much.

Emacs Lisp seems to serve its purpose as it is.  It's not a functional
programming language, and it doesn't need to be one.  Forget I ever asked.

Re: segfault after changing max-lisp-eval-depth and max-specpdl-size

[Richard Stallman]

    That means I'll have to use let/while/setq instead of recursion
    in order to "Avoid arbitrary limits", which produces less
    enjoyable code.

Although max-lisp-eval-depth is an arbitrary limit, the non-arbitrary
limit of the stack size lies behind it.  A program that needs to
recurse for each element in a long or deep data structure really can't
work, in the absence of a tail-recursive interpreter.  If we succeed
in rehosting Emacs on Guile, which is a long-term plan, tail-recursion
would work.  Until that day, you simply have to use iteration.