GNU bug report logs - #33034
`unwind-protect' cleanup form is not executed if body dies in stack overflow

Previous Next

Package: emacs;

Reported by: Paul Pogonyshev <pogonyshev <at> gmail.com>

Date: Sat, 13 Oct 2018 10:09:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Subject: bug#33034: closed (Re: `unwind-protect' cleanup form is not
 executed if body dies in stack overflow)
Date: Sun, 14 Oct 2018 17:04:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 33034 <at> debbugs.gnu.org.

-- 
33034: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33034
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 33034-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: `unwind-protect' cleanup form is not executed if body dies in
 stack overflow
Date: Sun, 14 Oct 2018 10:02:59 -0700
[Message part 3 (text/plain, inline)]
Thanks for the bug report; I installed the attached to fix it. The problem with 
your test case was neither C stack overflow nor failure to unwind the Lisp 
stack: it was failure to restore the Lisp evaluation depth (which is a separate 
thing from the Lisp stack size).

By the way, why are there two different limits? That slows the interpreter down 
a bit.  Why don't we simply have a limit for the Lisp stack size? Every time 
lisp_eval_depth grows, the stack size grows, so limiting the stack limits the 
evaluation depth for free. If we had done things this way, the interpreter would 
be a bit faster and this bug would never have occurred.
[0001-Fix-lisp_eval_depth-in-unwind-protect-cleanup.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: `unwind-protect' cleanup form is not executed if body dies in stack
 overflow
Date: Sat, 13 Oct 2018 12:07:48 +0200
To reproduce:

    (defun overflow ()
      (overflow))
    (defun test ()
      (interactive)
      (message "BEFORE")
      (unwind-protect
          (overflow)
        (message "CLEANUP")))

Invocation of `test' never issues message "CLEANUP", whether it is run
interactively or non-interactively.

By comparison, if you _catch_ the error with `condition-case':

    (defun test-2 ()
      (interactive)
      (message "BEFORE")
      (unwind-protect
          (ignore-errors (overflow))
        (message "CLEANUP")))

then cleanup form is executed properly.

But if your error catcher is "above" the `unwind-protect' form, the
cleanup is not executed again, even though the error is eaten as
expected:

    (defun test-3 ()
      (interactive)
      (message "BEFORE")
      (ignore-errors
        (unwind-protect
            (overflow)
          (message "CLEANUP"))))

This is a perfect way to screw up your Emacs permanently (until full
restart): when some `unwind-protect' cleanups are not run, you can be
left with unexpected function advices, permanently altered global
state etc., without any good way to undestand what's wrong.

Paul



This bug report was last modified 6 years and 222 days ago.

Previous Next


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