From unknown Fri Jun 20 18:13:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#33034 <33034@debbugs.gnu.org> To: bug#33034 <33034@debbugs.gnu.org> Subject: Status: `unwind-protect' cleanup form is not executed if body dies in stack overflow Reply-To: bug#33034 <33034@debbugs.gnu.org> Date: Sat, 21 Jun 2025 01:13:43 +0000 retitle 33034 `unwind-protect' cleanup form is not executed if body dies in= stack overflow reassign 33034 emacs submitter 33034 Paul Pogonyshev severity 33034 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 06:08:11 2018 Received: (at submit) by debbugs.gnu.org; 13 Oct 2018 10:08:11 +0000 Received: from localhost ([127.0.0.1]:47749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBGqB-0000ro-6j for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:08:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49697) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBGq9-0000rb-VM for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:08:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBGq3-0000oC-O8 for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:08:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56682) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gBGq3-0000o5-JT for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:08:03 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBGq2-0006FK-PR for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:08:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBGq2-0000nW-2J for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:08:02 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:32969) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gBGq1-0000mZ-R2 for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 06:08:01 -0400 Received: by mail-wr1-x430.google.com with SMTP id e4-v6so15933047wrs.0 for ; Sat, 13 Oct 2018 03:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=i6szwkQk6hFG4GRd6rOrXwK06PsABFpL7YVX/1V3Ly4=; b=E6xfbbJemjQBOJFP60I8oxyZMVkv0kJshNbbL24G5B5o6ul2C5AfNkFeb6gmHSZvBJ Vqi5FRiWlcCEaX9Ml2+XIjOp3XibZGdOMZKhOxC6M3UeelW7sLu6q301wx3w1s2RdXI2 IT0eYWMj/FKzT6NKYUhPSd2RtIJpqEbGvFO84KtEwTsNbMHDJtAfCR/EU7E4JVryxafP OZqwnECbhqokbUTCtW9esBxzAA5/cAnnuLVC+Ivguy+mfawjY9duZh6paOqrci114UlK kf0CVV8KGrPbN8LZVVcT32m7wrWbT0Cx9dcTbqwMNxgbN+5sCVVCPi7Yoy19rTiUV4RB gfIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=i6szwkQk6hFG4GRd6rOrXwK06PsABFpL7YVX/1V3Ly4=; b=Y7yjfadNS7Ua+7PbegWEWFOIaJ4NfNTKfGsCGip9LXUVUZ6TXc5wV23HlHwva4Ure9 IdGjO+Vwdxuw/q94cMEjOHC0Ci6VN6CbQjdtJzDV9agw477A1cwh3ZM0Vdtr+/hayzs8 4orD+Rt36GzdI/g/6O5gwmmUG/lPVvoUuBLu8iPh9JkPa6AYs8mCG0dC8OV1mpUpJRie AmGqBd0cpIbcLn6rQNjT0tJ7Gyql87qR6eAvC+sIljdutw6r1auqPkuLyJzTXw3SIfj6 JzX6KKDEN8QtQRLnHyIhjVayTd5euqgrK5aics29h3oqvrYY0IFb0UtYBAdWg+xhtMT5 Us/A== X-Gm-Message-State: ABuFfogbT5LodH4bKJDgy1/yDWZEYph+uGtTgOAVH0lUiHELPA+tkGfe GtV7M0U/YMDn0VY8VEN3cxQwcgbvsXqUJJ9u8WRwPuI= X-Google-Smtp-Source: ACcGV60Hpk0IbjkeM/0N0o0G21b0tnW0CyZ/LD7qXCVI4vqbf0WTiH499aZPOJjU2fQ30kdqpKhn+E1MS5cFcQzPP7Y= X-Received: by 2002:adf:9244:: with SMTP id 62-v6mr7771869wrj.130.1539425279470; Sat, 13 Oct 2018 03:07:59 -0700 (PDT) MIME-Version: 1.0 From: Paul Pogonyshev Date: Sat, 13 Oct 2018 12:07:48 +0200 Message-ID: Subject: `unwind-protect' cleanup form is not executed if body dies in stack overflow To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 06:29:22 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 10:29:22 +0000 Received: from localhost ([127.0.0.1]:47766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHAf-0001S5-BR for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:29:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHAc-0001Rr-HP for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:29:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBHAS-00021L-VV for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:29:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBHAS-00021H-Rc; Sat, 13 Oct 2018 06:29:08 -0400 Received: from [176.228.60.248] (port=4054 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBHAS-0003lp-FS; Sat, 13 Oct 2018 06:29:08 -0400 Date: Sat, 13 Oct 2018 13:29:13 +0300 Message-Id: <83k1mmuoli.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-reply-to: (message from Paul Pogonyshev on Sat, 13 Oct 2018 12:07:48 +0200) Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Paul Pogonyshev > 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. You are not supposed to continue using Emacs as usual after it recovered from a C stack overflow. You are supposed to exit Emacs and restart the session. The C stack overflow recovery is provided to allow you to save your edits instead of losing them. P.S. I was somehow certain that we say the above somewhere in the docs, but I cannot find it, so maybe I was dreaming. Patches to add that are welcome. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 06:36:04 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 10:36:04 +0000 Received: from localhost ([127.0.0.1]:47774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHHA-0001dQ-FD for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:36:04 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:33059) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHH9-0001cv-6E for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:36:03 -0400 Received: by mail-wr1-f47.google.com with SMTP id e4-v6so15981058wrs.0 for <33034@debbugs.gnu.org>; Sat, 13 Oct 2018 03:36:03 -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=zlbP19V8795KWzmLWwnuF2QAZ8BqGRREIUA4red0lRM=; b=uyoqQLSpSV+rlLB0GC1qluJGsSV/suQQkVZ5EEa6BexF5VBUBJ/7ZbbU9ReLywRxMD VXpOmlZ1oI6+L+dBncd78Nb8KfS7ZjQVcMWEc+iCMXBntGp21urxvNpkum5SF6CENgr3 WaJBig8JCXun9PAMDVnWGKK9tAdza0Z+SigEgsPpkgIsmQjuZV3rMucV/eYyFjFeHt0w FBxDLOQ/J9nraipxh0lv89oSuk7vAH5DT6Ug34L1c6PTbTjAQk1gaI05+mE+4ObBHOyi vORtetSgtSkJBr/8o3PVE8XFoLgUPukNJDldc/R4pduBp1FBJc2Xx6vCH1yW7h+CFRow 9k8g== 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=zlbP19V8795KWzmLWwnuF2QAZ8BqGRREIUA4red0lRM=; b=kv2swt9c5WlB8BL5Li0oEslEBKY27VYpzR0m4qjHBMIzL08dt3ArSNtow5B6VPDqKg k4Al0daMMTQ7oZWzEgJL9T2Pbu720Vc1INUfGG2RshYG9rLzTVW2qcxgUmMmYqgLt58U NXogNlkMQU/vOpC72mFXuCEFyru9GMIjpYZcy6yokemAzThjiH8E2oG2qcWxeagbkk61 553DUI3jCs3gbquUXY6yppwrB3/70TQdgkcuWPKw/4QGuyq627SUpDVF22wE/JQVV0Yt +jrPyJz5UDez7iwY8JG02O5V3pe11xaykH6zkiJMGCWHfMfhu2EtL0z+tIjystxGqyfs sv2Q== X-Gm-Message-State: ABuFfogebHglvsEiaonGA+zNZ/KWJiLj6qrszpy8rGAIsgocq0jncUnB N/Z7GIGfxhrWAVowhL0N3tiScCl8HlJj4w9OBw== X-Google-Smtp-Source: ACcGV61x6LO5Z//UgbofmABq7F9mswW6SZD49LTL1a3Vldsm2yHGY4/zEuBbhV5k0ObOS/GTDMl5A8pF3RRWYnWfUIk= X-Received: by 2002:adf:e542:: with SMTP id z2-v6mr7673999wrm.53.1539426957387; Sat, 13 Oct 2018 03:35:57 -0700 (PDT) MIME-Version: 1.0 References: <83k1mmuoli.fsf@gnu.org> In-Reply-To: <83k1mmuoli.fsf@gnu.org> From: Paul Pogonyshev Date: Sat, 13 Oct 2018 12:35:46 +0200 Message-ID: Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I see. Wonderful approach. At least I'm not supposed to restart my machine. On Sat, 13 Oct 2018 at 12:29, Eli Zaretskii wrote: > > > From: Paul Pogonyshev > > 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. > > You are not supposed to continue using Emacs as usual after it > recovered from a C stack overflow. You are supposed to exit Emacs and > restart the session. > > The C stack overflow recovery is provided to allow you to save your > edits instead of losing them. > > P.S. I was somehow certain that we say the above somewhere in the > docs, but I cannot find it, so maybe I was dreaming. Patches to add > that are welcome. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 06:45:44 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 10:45:44 +0000 Received: from localhost ([127.0.0.1]:47788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHQW-0001sK-8K for submit@debbugs.gnu.org; Sat, 13 Oct 2018 06:45:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHQU-0001s3-Ph for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:45:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBHQM-0001jJ-Bf for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 06:45:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBHQM-0001jF-7W; Sat, 13 Oct 2018 06:45:34 -0400 Received: from [176.228.60.248] (port=1094 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBHQL-0002ks-Nb; Sat, 13 Oct 2018 06:45:34 -0400 Date: Sat, 13 Oct 2018 13:45:38 +0300 Message-Id: <83in26unu5.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-reply-to: (message from Paul Pogonyshev on Sat, 13 Oct 2018 12:35:46 +0200) Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow References: <83k1mmuoli.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 06:52:32 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 10:52:32 +0000 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 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 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) MIME-Version: 1.0 References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> In-Reply-To: <83in26unu5.fsf@gnu.org> From: Paul Pogonyshev Date: Sat, 13 Oct 2018 12:52:13 +0200 Message-ID: Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 07:01:09 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 11:01:09 +0000 Received: from localhost ([127.0.0.1]:47800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHfR-0002H2-Bt for submit@debbugs.gnu.org; Sat, 13 Oct 2018 07:01:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBHfO-0002GQ-I0 for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 07:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBHfE-0000l2-Fk for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 07:01:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBHfE-0000kt-9t; Sat, 13 Oct 2018 07:00:56 -0400 Received: from [176.228.60.248] (port=2037 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBHfD-0001oa-8Y; Sat, 13 Oct 2018 07:00:56 -0400 Date: Sat, 13 Oct 2018 14:01:00 +0300 Message-Id: <83ftxaun4j.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-reply-to: (message from Paul Pogonyshev on Sat, 13 Oct 2018 12:52:13 +0200) Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Paul Pogonyshev > Date: Sat, 13 Oct 2018 12:52:13 +0200 > Cc: 33034@debbugs.gnu.org > > I haven't looked into the source code, but it seems that these > examples don't involve C-level stack overflow. You are right, this issue is unrelated to C stack overflow. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 07:30:07 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 11:30:07 +0000 Received: from localhost ([127.0.0.1]:47814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBI7P-00032F-3T for submit@debbugs.gnu.org; Sat, 13 Oct 2018 07:30:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBI7N-00031C-Mp for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 07:30:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBI7F-0007Ry-56 for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 07:29:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBI7F-0007Ru-1V; Sat, 13 Oct 2018 07:29:53 -0400 Received: from [176.228.60.248] (port=3824 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBI7E-0005er-JS; Sat, 13 Oct 2018 07:29:52 -0400 Date: Sat, 13 Oct 2018 14:29:57 +0300 Message-Id: <83efcuulsa.fsf@gnu.org> From: Eli Zaretskii To: pogonyshev@gmail.com In-reply-to: <83ftxaun4j.fsf@gnu.org> (message from Eli Zaretskii on Sat, 13 Oct 2018 14:01:00 +0300) Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> <83ftxaun4j.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > Date: Sat, 13 Oct 2018 14:01:00 +0300 > From: Eli Zaretskii > Cc: 33034@debbugs.gnu.org > > > I haven't looked into the source code, but it seems that these > > examples don't involve C-level stack overflow. > > You are right, this issue is unrelated to C stack overflow. What actually happens here is that the cleanup form _is_ called, but it again hits the limit of Lisp local bindings, and therefore itself signals an error. And unwind-protect does not protect cleanup forms (this is documented). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 07:38:29 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 11:38:30 +0000 Received: from localhost ([127.0.0.1]:47819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBIFZ-0005FD-MN for submit@debbugs.gnu.org; Sat, 13 Oct 2018 07:38:29 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:44359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBIFY-0005F1-FG for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 07:38:28 -0400 Received: by mail-wr1-f42.google.com with SMTP id 63-v6so16050963wra.11 for <33034@debbugs.gnu.org>; Sat, 13 Oct 2018 04:38:28 -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=3u14YxfdPzDha+Lxf3IK3K5gcXTdnPFsBCJWHUNFO8E=; b=UaJUGf4/L20zEG0iFHdW6wcjkHFDMi9GC1aI477APBentcRzhgdseKkMLFhR9DzsVE hnB5/eL0wlwb7gqLWT8I/kkMNy1kPpctIfVUFGj1ys6Em2klO4gtNGf1mcz/II1PfzWe pyZXtR6l0h2pBwutO/bZIx/ClTNnw1/kLFTeITeJw3JkQ8bV/9rqQUOhmvjs3COsqqgM wuVPJUIoKuxRHPGdslFbcpSK0Kp9lFgXb84pczBZBU2dMVuZxWL9Xeqaw+f/f9bRnQ/P KO7r0/kJENeKcA4/kRWseEQH03WFnUyz2sOuYqiV9RNsYdTuAiRMM3Nc+Rt/UIoWbbMJ oFmw== 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=3u14YxfdPzDha+Lxf3IK3K5gcXTdnPFsBCJWHUNFO8E=; b=aOKYInkNW1vTRLHTRjaLH8RdHrImG2hiyMJEjFvHSfnkjPI9Rdqv7Lqg/J14j9u49F OR1hA+01t5faBvUbJKf8UAur0Eu6H5wGJWwKke8jVCQVXNaYi2fV7rEvR/OfY54FIRQC lVV1D/oYhmuR1XxtHdMNlAlQkftEfn18VCPuOMWCZMXB9bbNoZw8emi9OQjshFAWso9t YTutmMhRUirNROfgmZcie/mSoim0eEQnRAbVt1/XNsnXcvXTkU7NEvAt5dbQX8SEgB6g TYCmfJIZlD2rC+0SoLehvJWetQ1vinhgJ0w0R47f6jvGVOmm6B+Jxhy+c0h/X2qHK/mg fAqA== X-Gm-Message-State: ABuFfoj/zNXzDxbym0No+YH9yAhyGSLBBSFUILV7tEImVPJ6d/DRO229 TLOnmbsLqtKbA5q6GRWxU5byrcxQze/HwcIiaA== X-Google-Smtp-Source: ACcGV634opXMg/yo7GZGrnRo/k8spVNjnktBa/AEBiJWAgVSaDvPvHY9tX6tM3cr+HOxtYh8HGMNOcss/R2Cak7Nliw= X-Received: by 2002:adf:9244:: with SMTP id 62-v6mr7958061wrj.130.1539430702731; Sat, 13 Oct 2018 04:38:22 -0700 (PDT) MIME-Version: 1.0 References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> <83ftxaun4j.fsf@gnu.org> <83efcuulsa.fsf@gnu.org> In-Reply-To: <83efcuulsa.fsf@gnu.org> From: Paul Pogonyshev Date: Sat, 13 Oct 2018 13:38:11 +0200 Message-ID: Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. Paul On Sat, 13 Oct 2018 at 13:30, Eli Zaretskii wrote: > > > Date: Sat, 13 Oct 2018 14:01:00 +0300 > > From: Eli Zaretskii > > Cc: 33034@debbugs.gnu.org > > > > > I haven't looked into the source code, but it seems that these > > > examples don't involve C-level stack overflow. > > > > You are right, this issue is unrelated to C stack overflow. > > What actually happens here is that the cleanup form _is_ called, but > it again hits the limit of Lisp local bindings, and therefore itself > signals an error. And unwind-protect does not protect cleanup forms > (this is documented). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 08:35:43 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 12:35:43 +0000 Received: from localhost ([127.0.0.1]:47840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBJ8x-0000DB-DE for submit@debbugs.gnu.org; Sat, 13 Oct 2018 08:35:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBJ8v-0000Cx-Ji for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 08:35:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBJ8m-0007DB-Ff for 33034@debbugs.gnu.org; Sat, 13 Oct 2018 08:35:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBJ8m-0007D3-Bd; Sat, 13 Oct 2018 08:35:32 -0400 Received: from [176.228.60.248] (port=3923 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBJ8j-0006AW-JN; Sat, 13 Oct 2018 08:35:31 -0400 Date: Sat, 13 Oct 2018 15:35:34 +0300 Message-Id: <83bm7yuiqx.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-reply-to: (message from Paul Pogonyshev on Sat, 13 Oct 2018 13:38:11 +0200) Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> <83ftxaun4j.fsf@gnu.org> <83efcuulsa.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 13 10:02:28 2018 Received: (at 33034) by debbugs.gnu.org; 13 Oct 2018 14:02:28 +0000 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 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 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) MIME-Version: 1.0 References: <83k1mmuoli.fsf@gnu.org> <83in26unu5.fsf@gnu.org> <83ftxaun4j.fsf@gnu.org> <83efcuulsa.fsf@gnu.org> <83bm7yuiqx.fsf@gnu.org> In-Reply-To: <83bm7yuiqx.fsf@gnu.org> From: Paul Pogonyshev Date: Sat, 13 Oct 2018 16:02:09 +0200 Message-ID: Subject: Re: bug#33034: `unwind-protect' cleanup form is not executed if body dies in stack overflow To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33034 Cc: 33034@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) (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. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 14 13:03:14 2018 Received: (at 33034-done) by debbugs.gnu.org; 14 Oct 2018 17:03:14 +0000 Received: from localhost ([127.0.0.1]:49475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBjnO-00038Z-HH for submit@debbugs.gnu.org; Sun, 14 Oct 2018 13:03:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBjnM-00038M-FH for 33034-done@debbugs.gnu.org; Sun, 14 Oct 2018 13:03:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5AD431609A0; Sun, 14 Oct 2018 10:03:06 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zkh3BIPifpFe; Sun, 14 Oct 2018 10:03:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0DDCC160E48; Sun, 14 Oct 2018 10:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D23C8eBRSts6; Sun, 14 Oct 2018 10:03:04 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C1E9B1609A0; Sun, 14 Oct 2018 10:03:04 -0700 (PDT) To: Paul Pogonyshev From: Paul Eggert Subject: Re: `unwind-protect' cleanup form is not executed if body dies in stack overflow Organization: UCLA Computer Science Department Message-ID: <3f05af02-38e2-c03a-8449-bad3d1bb7670@cs.ucla.edu> Date: Sun, 14 Oct 2018 10:02:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------398AD4004868A0B1D8E44526" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 33034-done Cc: 33034-done@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------398AD4004868A0B1D8E44526 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------398AD4004868A0B1D8E44526 Content-Type: text/x-patch; name="0001-Fix-lisp_eval_depth-in-unwind-protect-cleanup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-lisp_eval_depth-in-unwind-protect-cleanup.patch" >From 5dfbdff57be6e93efe79f9b07e8b6383ec02959a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 14 Oct 2018 09:51:32 -0700 Subject: [PATCH] Fix lisp_eval_depth in unwind-protect cleanup Problem reported by Paul Pogonyshev (Bug#33034). * src/lisp.h (union specbinding): New member unwind.eval_depth. * src/eval.c (record_unwind_protect, set_unwind_protect): Set it. (do_one_unbind): Use it. --- src/eval.c | 3 +++ src/lisp.h | 1 + 2 files changed, 4 insertions(+) diff --git a/src/eval.c b/src/eval.c index 42c275de6b..a51d0c9083 100644 --- a/src/eval.c +++ b/src/eval.c @@ -3429,6 +3429,7 @@ record_unwind_protect (void (*function) (Lisp_Object), Lisp_Object arg) specpdl_ptr->unwind.kind = SPECPDL_UNWIND; specpdl_ptr->unwind.func = function; specpdl_ptr->unwind.arg = arg; + specpdl_ptr->unwind.eval_depth = lisp_eval_depth; grow_specpdl (); } @@ -3501,6 +3502,7 @@ do_one_unbind (union specbinding *this_binding, bool unwinding, switch (this_binding->kind) { case SPECPDL_UNWIND: + lisp_eval_depth = this_binding->unwind.eval_depth; this_binding->unwind.func (this_binding->unwind.arg); break; case SPECPDL_UNWIND_ARRAY: @@ -3595,6 +3597,7 @@ set_unwind_protect (ptrdiff_t count, void (*func) (Lisp_Object), p->unwind.kind = SPECPDL_UNWIND; p->unwind.func = func; p->unwind.arg = arg; + p->unwind.eval_depth = lisp_eval_depth; } void diff --git a/src/lisp.h b/src/lisp.h index 5ecc48b025..a7a26ef350 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3071,6 +3071,7 @@ union specbinding ENUM_BF (specbind_tag) kind : CHAR_BIT; void (*func) (Lisp_Object); Lisp_Object arg; + EMACS_INT eval_depth; } unwind; struct { ENUM_BF (specbind_tag) kind : CHAR_BIT; -- 2.17.1 --------------398AD4004868A0B1D8E44526-- From unknown Fri Jun 20 18:13:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 12 Nov 2018 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator