From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Tue, 22 Dec 2015 12:52:05 -0800 Message-ID: <5679B7F5.9030504@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <83io4nuc68.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <83oadiqxq1.fsf@gnu.org> <5679B33E.9000804@dancol.org> <83y4cmp5y5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W9BVaPUa81LxkWbAeFKtjI3U5SCFbooff" X-Trace: ger.gmane.org 1450817554 28512 80.91.229.3 (22 Dec 2015 20:52:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 20:52:34 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, eggert@cs.ucla.edu, tzz@lifelogs.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 21:52:32 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aBTv5-00018U-Uo for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 21:52:32 +0100 Original-Received: from localhost ([::1]:52927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTv5-0003oA-Eb for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 15:52:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTup-0003np-TH for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:52:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBTuo-00061K-Pt for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:52:15 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTuo-00061G-Ef; Tue, 22 Dec 2015 15:52:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=69uXu2X20xgUhNIsrVALuOwq8NKFEUet5fDjQ70QKlE=; b=OEIQy+rCsbtlmtdQmb0AZiSQe8i/iXVoPfue2G+BQ7zMzRewCcjvIExxqdJcdsCXgJbIjHfO4AyI38AfC0lh9JS4Os6BS94pHyfOAF7PDczikrLKyRZPVKhlp9ykiVoI3O61MyrwJVWwPIVsUuon8hCswygciQnnSp9C7EgYTtwodB3o2yuNcJs5TUaobS2iegd+HlRGrWjZTzJGwU1wBWbke1HO3Ai5ntWmSvGovOQvdk12RAHxgpOe/h7+O2NQkAZa5KDJGWhNrng+jS5KEThUJWvH+8fwYHcpSwp4GZwrnye4eBxmQkr8Ka57LRqOWJevxQilA7QbubWZRJkFWw==; Original-Received: from [2620:10d:c090:180::d628] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aBTum-0008WN-3n; Tue, 22 Dec 2015 12:52:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83y4cmp5y5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196691 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W9BVaPUa81LxkWbAeFKtjI3U5SCFbooff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/22/2015 12:46 PM, Eli Zaretskii wrote: >> Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com, >> p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Tue, 22 Dec 2015 12:31:58 -0800 >> >>> I very much doubt that. The alternate stack is quite small (AFAIK, >>> the standard value that we are using, SIGSTKSZ, is something like >>> 8KB). Running arbitrary C++ code on such a small stack is not safe. >>> (My understanding is that the value of SIGSTKSZ should suffice for >>> calling printf, and that's about it.) There will be high risk of >>> hitting yet another stack overflow, this time a fatal one. >> >> We're not talking about running arbitrary C++ code on the small stack.= >> The longjmp transfers execution to the original stack, but with the >> context popped off. >> >> Overflow stack: A B C D E F G >> Signal stack: 1 2 3 longjmp >> Resumption stack: A B C >=20 > If you only longjmp a short while, you have no idea how much stack you > freed. You might as well be just 200 bytes below the level where the > stack overflow hit. Which is why you setjmp in places where you have a significant stack reserve. > That's why we jump to the lowest level we can: there, we _know_ we > have enough stack to do any kind of stuff. >=20 >>> You are in effect saying the stack overflow recovery code should not >>> have been added to Emacs. But we already decided that an attempt to >>> recover is a useful feature, and I see no reason to go back. Even if= >>> this is works only in some cases, partial recovery is better than a >>> hard crash, because it lets users save their work. >> >> Or it actually corrupts their work, because the Emacs core is in a bad= >> state. >=20 > No, the core isn't in a bad state. Longjmp is not an abnormal path, > its semantics is very simple and clear. Longjmp, by itself, is simple and clear. What's unreliable is longjmping to Lisp at completely arbitrary points in the program, even ones marked "GC can't happen here" and the like. You say Emacs shouldn't crash. Fine. We can't make that guarantee if the crash recovery code breaks program invariants. If you want to longjmp, you need to do it at certain well-defined points only. The current approach is a bug machine. >> We can gracefully recover from stack overflow of Lisp code. We >> cannot recover from stack oveflow at arbitrary points in the C core. >=20 > We can and we do. The recovery has only to be good enough to allow > saving your work and exiting. That's the only goal of that > protection: allow the user to exit normally, after saving their work. I'd rather rely on autosaves. Failing that, we should allocate guard pages, unprotect the guard pages on overflow, and call out_of_memory so that it's obvious Emacs is in a bad state. This way, we don't have to longjmp out of arbitrary code sequences. --W9BVaPUa81LxkWbAeFKtjI3U5SCFbooff Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWebf1AAoJEN4WImmbpWBll6QP/j6eAcEcUwnnbfS8PxTcaK4e Rjg6VPIIRuLVpEsi/EzX4axYvvXDXf6CAGdgqqiR0f9O38ijtIjVivXW+O1NwbXQ MokptcZ/ZduShMr6h3sbsKBvanbSt/UnUA3S1GnWSQWhz6HP+J/3PBIH/nWag0DZ va305yXfTFSqReMrfq5f71+gUVXBKx9wohknD+F8Z8KhMtD5dOOySOURfHBjtXox dTtBoPG7XmoYtvuC43QT3+ql4bnrfci+SizgUEc0Ys8NP/8uXuCJmCdmfwYFX/YW G+E2n7cLQeOZ52rRq3xnTLzIxQN5cIIXQ3JidimDBUtp6LJNEyamhV3i8SMkvg81 hRHbsM87vsfalmRkEoZicNCm840Eu1jS6iKV5jCDNT0zPIFculhVPnsv4K8IK9XL x+Nx2QmFP0lbqi8eqSnlfbSJOfHqYpdLlX7Boeg4QpaZnBYrg3aCHELaEMC0Dlwb jBl7YEoOtyNZSGh7PGktlb9NwolyNnRPzNTcxkgfZTSesFZbC9gZ384tI8Sxjlol b6+SLOn2pabs7TrXI1hOANanAx3YvpV7OuNxw+C/FVRNXFefOcVg1J3t5eCI1UMP zFEK9L5qNB49G3kMCwwL2Xa6xafAVzhyYWLX4D47Mqxpo0SDj2cRXYvaxCyhk6jz +pumUG1Gwb3Mt0CqWqAk =Glzu -----END PGP SIGNATURE----- --W9BVaPUa81LxkWbAeFKtjI3U5SCFbooff--