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 12:52:13 +0200 Message-ID: References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.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 1539427866 17395 195.159.176.226 (13 Oct 2018 10:51:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2018 10:51:06 +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 12:51:02 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 1gBHVd-0004ML-3q for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 12:51:01 +0200 Original-Received: from localhost ([::1]:44479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBHXj-0003mU-MY for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 06:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBHXd-0003mN-AZ for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:53:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBHXa-00060H-2A for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:53:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43534) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gBHXZ-00060A-Ud for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:53:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gBHXZ-00023U-N7 for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:53:01 -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 10:53:01 +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.15394279527858 (code B ref 33034); Sat, 13 Oct 2018 10:53:01 +0000 Original-Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 10:52:32 +0000 Original-Received: from localhost ([127.0.0.1]:47792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHX6-00022f-0V for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:52:32 -0400 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:32899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHX4-00022M-DV for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:52:30 -0400 Original-Received: by mail-wr1-f45.google.com with SMTP id e4-v6so16007757wrs.0 for <33034@debbugs.gnu.org>; Sat, 13 Oct 2018 03:52:30 -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=iCRuGWMkkudkHkHYy1ngJqsDg6FYLcNehDWKmDqxHuA=; b=RK8GH+TBYRbhwUA6+O2d6a+SuAN5DPBbEOGe7o4ccCCbfhEVQ/pfm3ApXr5K4ewLVJ SLgBPGbRIHSyG6MUOQs+J2QRjn02nQU23NSXtpd17FceA4lTiJ+NSeFi81tuQfxIdPx9 oLjbAWcgwyJidh+JaGYn8DT1QV9IQYXUT6RQ+QDuDf8j8MREX+EyrutpaVnBkdfX1T0q Vm+ZNZ6NmVzbX2TmB/K5YmdVnRXr4CJXayM6deerOnd4L9kDovfFzdawAuhmyvd7c7bN 8dwDv5K6+7SeKAjRNdLVm+1CQ2m2cx0wKV4MDCl+8/j5peKrEI3YEv6R8q+ePV7UHQbz 78JA== 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=iCRuGWMkkudkHkHYy1ngJqsDg6FYLcNehDWKmDqxHuA=; b=rybAqma9aiL/gFG9P5UMQcIRCSXIz2q9oqQNXnXnzzd3UW6+ArZHCafOC6YVvrA0Ny l4K44CfhFQ3PLx3sKzhaI7i7o4IYP/7PqEr853Zt50AgC/kDfkPLG6Vv5mbttoJhUofO edQ1cfvNY2c+VgW8kjrEueVqdWHqJ/nMvKPirhhUoihputDPLLTJWjTZu5F+C7N2OaVO AGVfql3kcFwaVRBjOFYQ1N/D8N15oC6cEdpp/5pZU6dyCr9gUSyCHP2TX7OOvV832K1Y PwV26RR430lE4AX9Vj1Q0JASQbY0xp2/s5AFysuRlfwuIBjsykqAfPBk5nDnM2yjIBAM xjSg== X-Gm-Message-State: ABuFfoh1ADmnUyYEXLfSG651MeDP/LpXrxmPBpiANj9F3coXP8lJRV6b Cmw6N3CB3u9ziLvNgcYS+iiIn/aKM08KKNh62DnCVV0= X-Google-Smtp-Source: ACcGV60PJKC4OIbeYouOIN2qrzaJJaYHWd4GT+3LXDSoK+ibzXBx0bIZ8WxXQW5zpLueegQnWtm9dpc5i6uLgKhfbZA= X-Received: by 2002:adf:f4c3:: with SMTP id h3-v6mr7711128wrp.259.1539427944640; Sat, 13 Oct 2018 03:52:24 -0700 (PDT) In-Reply-To: <83in26unu5.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:151211 Archived-At: I haven't looked into the source code, but it seems that these examples don't involve C-level stack overflow. I tried setting `attempt-stack-overflow-recovery' to nil and re-evaluated the examples with exactly the same results: cleanup forms are not executed, but Emacs doesn't crash. Looks like stack that is overflown here is only Lisp-level. Besides, it's hard to imagine that `max-specpdl-size' or `max-lisp-eval-depth' somehow affect C-level stack. On Sat, 13 Oct 2018 at 12:45, Eli Zaretskii wrote: > > > From: Paul Pogonyshev > > Date: Sat, 13 Oct 2018 12:35:46 +0200 > > Cc: 33034@debbugs.gnu.org > > > > I see. Wonderful approach. > > If you have ideas for better approaches, I'm sure they will be > welcome. > > C stack overflow results in SIGSEGV; the current code attempts > recovery by using OS-dependent techniques that analyze the data > provided by the segfault to detect when it's a stack overflow, and if > so, do the moral equivalent of (throw 'top-level), bypassing any > possible unwind forms, because evaluating those forms when there is no > available stack space might very well trigger another, nested > segfault. > > It's a hard problem, and the only justification for it is to give > users some imperfect chance of saving their edits. > > Some people think we shouldn't even attempt to recover from such > calamities, and instead just crash, which is why we have the > attempt-stack-overflow-recovery variable to let those people have what > they want.