Re: Segmentation fault for large values of max-lisp-eval-depth

[Eli Zaretskii]

> From: Jesper Harder <address@hidden>
> Date: Thu, 29 Apr 2004 03:56:59 +0200
> 
> > The stack limit is stored in a global variable whose name is
> > specific to the C library used to link Emacs.  I don't know the name
> > of that variable for your library, but asking some guru for your OS
> > would probably produce the answer.
> 
> I have no idea how to figure out that name (why doesn't the glibc
> documentation tell?).

Sounds like a documentation bug, perhaps you should report that.

Anyway, here's the recipe to find out the name of that variable at
GDB's prompt:

   foo$ gdb ./emacs
   (gdb) break main
   (gdb) run -q
   (gdb) info variables .*stack.*

(The first 2 commands are so that libc.so is loaded and GDB could see
variables defined by it.)  If I do that on a Debian system, I get
this fragment near the end of what GDB prints:

    Non-debugging symbols:
    0x4018cb20  obstack_alloc_failed_handler
    0x4018cb24  obstack_exit_failure
    0x40193494  _obstack
    0x4001340c  __libc_stack_end

And then I can print the value:

    (gdb) p/x __libc_stack_end
    $1 = 0xbfffee2c

So in my case, the stack top seems to be at 0xbfffee2c.  If that's
your value as well, then 0xbf7ffff4, which is lower, is indeed a
symptom of a stack overflow, since the stack grows downwards.

> But increasing the stack with 'ulimit -s' stops Emacs from crashing
> for this particular value of `max-lisp-eval-depth'.  I suppose that
> means that the stack _did_ overrun?

Probably.