GNU bug report logs - #16603
24.3.50; Segfault when viewing a backtrace

Previous Next

Full log

Message #11 received at 16603 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: larsi <at> gnus.org, 16603 <at> debbugs.gnu.org
Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace
Date: Fri, 31 Jan 2014 10:10:17 +0200

> Date: Fri, 31 Jan 2014 11:03:16 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> Cc: 16603 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.