bug#16603: 24.3.50; Segfault when viewing a backtrace

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 11:03:16 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: 16603@debbugs.gnu.org
> 
> On 01/31/2014 06:20 AM, Lars Ingebrigtsen wrote:
> 
> > (require 'gnus-group)
> > (setq debug-on-error t)
> > (gnus-read-ephemeral-emacs-bug-group 16577)
> >
> > Choose Rotem's article, and my Emacs crashes:
> 
> Reproduced.  With the only extra eassert:
> 
> === modified file 'src/eval.c'
> --- src/eval.c        2014-01-25 03:48:29 +0000
> +++ src/eval.c        2014-01-31 06:49:49 +0000
> @@ -3191,6 +3191,7 @@
>   void
>   record_unwind_protect (void (*function) (Lisp_Object), Lisp_Object arg)
>   {
> +  eassert (specpdl_ptr < specpdl + specpdl_size);
>     specpdl_ptr->unwind.kind = SPECPDL_UNWIND;
>     specpdl_ptr->unwind.func = function;
>     specpdl_ptr->unwind.arg = arg;
> 
> I got the following backtrace:
> 
> #14 0x00000000005eafb9 in die (msg=0x70d440 "specpdl_ptr < specpdl + 
> specpdl_size", file=0x70c498 "../../trunk/src/eval.c",
>      line=3194) at ../../trunk/src/alloc.c:6761

Of course.  This can be seen in Lars's backtrace (note the error Emacs
is signaling in frame #28):

> #24 0x0000000000549f06 in call_debugger (arg=42128966) at eval.c:323
> #25 0x0000000000548e6d in maybe_call_debugger (data=42128918, sig=12077586, 
>     conditions=8579966) at eval.c:1724
> #26 Fsignal (error_symbol=12077586, data=42128918) at eval.c:1542
> #27 0x0000000000549039 in xsignal (error_symbol=<optimized out>, 
>     data=<optimized out>) at eval.c:1579
> #28 0x0000000000549704 in signal_error (
>     s=0x5ddc38 "Variable binding depth exceeds max-specpdl-size", 
> arg=12026162)
>     at eval.c:1634
> #29 0x0000000000549792 in grow_specpdl () at eval.c:2023
> #30 0x0000000000549886 in specbind (symbol=41539506, value=41896998)
>     at eval.c:3138

> IIUC this is a kind of chicken-egg problem: when we're running out of specpdl
> stack, we want to run a debugger, which, in turn, needs some specpdl space to 
> run.

So either we should reserve some space for the debugger, or enlarge
max-specpdl-size before running the debugger, or refrain from running
the debugger in this specific case.