Subject: Re: bug#31996: 27.0.50; [w32] while dumping: assertion failed: specpdl_ptr->kind == SPECPDL_UNWIND_PTR && specpdl_ptr->unwind_ptr.func == xfree

From: Paul Eggert <[email-masked]>
Date: Fri, 29 Jun 2018 11:18:31 -0700

On 06/29/2018 05:30 AM, Noam Postavsky wrote:
> You removed the bytecode stack in [1: a815e5f195], right?

Yes I did. Thanks for catching that. I fixed the comment by installing 
the attached into the emacs-26 branch.

>From e6be48a508c4d25c8f8973dc23708c924b403927 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Fri, 29 Jun 2018 11:14:36 -0700
Subject: [PATCH] * src/lisp.h: Omit obsolete comment re bytecode stack.

---
 src/lisp.h | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/lisp.h b/src/lisp.h
index 56ad8b814b..b2449cb87d 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3044,15 +3044,13 @@ extern void defvar_kboard (struct Lisp_Kboard_Objfwd *, const char *, int);
   } while (false)
 
 
-/* Elisp uses several stacks:
-   - the C stack.
-   - the bytecode stack: used internally by the bytecode interpreter.
-     Allocated from the C stack.
-   - The specpdl stack: keeps track of active unwind-protect and
-     dynamic-let-bindings.  Allocated from the `specpdl' array, a manually
-     managed stack.
-   - The handler stack: keeps track of active catch tags and condition-case
-     handlers.  Allocated in a manually managed stack implemented by a
+/* Elisp uses multiple stacks:
+   - The C stack.
+   - The specpdl stack keeps track of backtraces, unwind-protects and
+     dynamic let-bindings.  It is allocated from the 'specpdl' array,
+     a manually managed stack.
+   - The handler stack keeps track of active catch tags and condition-case
+     handlers.  It is allocated in a manually managed stack implemented by a
      doubly-linked list allocated via xmalloc and never freed.  */
 
 /* Structure for recording Lisp call stack for backtrace purposes.  */
@@ -3131,7 +3129,7 @@ SPECPDL_INDEX (void)
    control structures.  A struct handler contains all the information needed to
    restore the state of the interpreter after a non-local jump.
 
-   handler structures are chained together in a doubly linked list; the `next'
+   Handler structures are chained together in a doubly linked list; the `next'
    member points to the next outer catchtag and the `nextfree' member points in
    the other direction to the next inner element (which is typically the next
    free element since we mostly use it on the deepest handler).
-- 
2.17.1