From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow Date: Sat, 13 Oct 2018 16:02:09 +0200 Message-ID: References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> <83ftxaun4j.fsf@gnu.org> <83efcuulsa.fsf@gnu.org> <83bm7yuiqx.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1539439275 30130 195.159.176.226 (13 Oct 2018 14:01:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2018 14:01:15 +0000 (UTC) Cc: 33034@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 13 16:01:11 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBKTd-0007kW-NU for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 16:01:09 +0200 Original-Received: from localhost ([::1]:45136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBKVk-0002nB-4j for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 10:03:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBKVW-0002j8-Vg for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 10:03:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBKVS-000819-VY for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 10:03:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44259) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gBKVS-000811-RE for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 10:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gBKVS-0002Yq-N6 for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 10:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Oct 2018 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33034 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33034-submit@debbugs.gnu.org id=B33034.15394393489795 (code B ref 33034); Sat, 13 Oct 2018 14:03:02 +0000 Original-Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 14:02:28 +0000 Original-Received: from localhost ([127.0.0.1]:48516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBKUu-0002Xv-6v for submit@debbugs.gnu.org; Sat, 13 Oct 2018 10:02:28 -0400 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:35079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBKUs-0002Xj-SE for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 10:02:27 -0400 Original-Received: by mail-wm1-f43.google.com with SMTP id e187-v6so15479629wmf.0 for <33034@debbugs.gnu.org>; Sat, 13 Oct 2018 07:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bu5rSTJjSPQIiX+U912YcqPBOa/SYT+XtR7wS1a9L8I=; b=hIWnZD9M/ri1WYAG/Lel1/JwZRLqbJ9IgI+XQSD6/AYEIwnOoom/nXszs6oL63oQBV JXv91+4kG/6exOMaBgTSXC4ODdG52JYpMXBLOyXOWV363RrZbbe+x0pV4aplhXdjB6M2 WDAH2Fs1S/Pf/eVQzf9mzZAaD8IzoBuUm+8TvxUkxxAjMt52R9xgmAswB7C0kwEg39iM jqE0RGrxLYL2jQiGFU7L9WuIj2apnbGS0aOiS8yr7x54h9nTObg4gVIgxVXEeEGzUtKi WpaGcH2qEYoJeDIjhvO+UYiDiuYMRfZTQlXVLjYfoYskRU9/Jq7e6iAynMgYJU9ENeEE ybQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bu5rSTJjSPQIiX+U912YcqPBOa/SYT+XtR7wS1a9L8I=; b=qbxsSXnw3GBC93dRw+tbYaQux4f18I7NvkzzYNIz0NI4m8iEv4/yUc8qAwblkfc2bY CKHZMJ21pJCgDpbeDOmaSSxSaezf+ffpqF9JicOWjwi84NmRqmlNfJc1ImW8uxdfs6B4 BF3S5Eo5R1MQf91gcovALS2DLBryqBYBi5aOo8Gn4is3ONiUx+l3v8m6LdGlpb8gQWhi JCdlflyVedAJ344yKv3cnTJC2nr6WwEeklsQX+PPDZDMHgn41GYK472gZZ+X9as8zWF+ a+vrtcEAoSY4kju6bbB68/1Aq/sedH4eA5b55bi5IcUH5kQsFp/erZdFq48Hrc7lT6Kx +smQ== X-Gm-Message-State: ABuFfogmHXkkNbi7UQXXXiPD1fVo/fMg7F4sslYk3VhoJMwdz8lFxmyL EEYJHC4hEg5oXa5N/DqqhClqB8eREtdAUfiWHoO9rwA= X-Google-Smtp-Source: ACcGV62OlMxz7R9t+TRTW3W9mTscVGi6q1EyOsb+w1rmBrX6kVPgQgJ5AXOE04qekXg2tNKBoWahJtNqC3VlgxppMeg= X-Received: by 2002:a1c:85d0:: with SMTP id h199-v6mr7935139wmd.127.1539439341067; Sat, 13 Oct 2018 07:02:21 -0700 (PDT) In-Reply-To: <83bm7yuiqx.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151224 Archived-At: (defvar global-test nil) (unwind-protect (let ((global-test t)) (message "inside, global-test = %s" global-test) (error "test")) (message "in cleanup, global-test = %s" global-test)) This gives the following output (outside the error): inside, global-test = t in cleanup, global-test = nil So, global variables are unwound, but stack is not? This doesn't make much sense to me. Besides, what is the purpose of current implementation? Current state has at least one disadvantage, highlighted by this bug: cleanup forms after a stack overflow error always fail to work, because stack is still full. Are there any advantages? I feel like it is more of coincidence than deliberate decision. Would fixing it break backwards compatibility? On Sat, 13 Oct 2018 at 14:35, Eli Zaretskii wrote: > > > From: Paul Pogonyshev > > Date: Sat, 13 Oct 2018 13:38:11 +0200 > > Cc: 33034@debbugs.gnu.org > > > > OK, but why does it hit the limit? Logically, by the time cleanup form > > is called, all the (overflow) stack frames should be removed and the > > cleanup form should see practically empty stack. It shouldn't be much > > different from calling cleanup without overflowing the stack to begin > > with. > > I don't think your expectation, that the stack should be unwound > before the cleanup runs, is correct. The implementation calls the > cleanup forms before it jumps to top-level, and I see nothing in the > documentation to promise anything different.