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:31:58 -0800 Message-ID: <5679B33E.9000804@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vklGpvokruXS0uJdMigusrNqwlgDg2GQA" X-Trace: ger.gmane.org 1450816428 11573 80.91.229.3 (22 Dec 2015 20:33:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 20:33:48 +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:33:39 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 1aBTco-00051r-Tj for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 21:33:39 +0100 Original-Received: from localhost ([::1]:52858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTco-0004Jl-AN for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 15:33:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTbW-0002vT-EP for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:32:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBTbS-0001uI-1y for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:32:18 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTbR-0001tr-Nr; Tue, 22 Dec 2015 15:32: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=5gICI3M+hMXIS6RlExShnJVp0i1Zs+W5PL/Qe+TpJuA=; b=hm1nf0X4S0A7n91ikHVaZ9xnn0Rod99tRjKyZF4+NcGqIzDbPrWJ/tRLYUMDRdlRW2k4dPELZgufn9ZJgKnDoyRX4T2IkiFujUX/h7LA/fnBfOevalcJ9f8bOamYQq6Hh7fJlaMS3BcBrOzyyogphfx7zfeSylDmv8FqE/5FkNBUaqjmq4FM5oXxjA6CjT+EuWlgZTuVIm9sfjc16aTyMf+0U0TksIu1F3shCaM3RmhRCYxQmRdggqFd9YcHozuy7MEA++B6yLKczJtdo8z+u4bO55UDWMQ2mCjSElCL2P+0aPrV4QISX6Uh0zCSHtYdWn7VDVKuF3K8yFZbud1qCg==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aBTbG-0008QV-In; Tue, 22 Dec 2015 12:32:02 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83oadiqxq1.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:196689 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vklGpvokruXS0uJdMigusrNqwlgDg2GQA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/22/2015 08:01 AM, Eli Zaretskii wrote: >> Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelog= s.com, >> emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Mon, 21 Dec 2015 20:38:07 -0800 >> >> Right now, when we get a SIGSEGV, we check the siginfo_t the OS gives = us >> by calling stack_overflow on it; if that returns true, we longjmp to >> toplevel. We configure the sigsegv handler to run on an alternate stac= k, >> so we'll always have space to do that much work. The longjmp restores >> the original stack. On the other side of the longjmp, we resume >> execution with our regular stack, but much further up the stack. At th= is >> point, we know we have a stack overflow, because nothing else longjmps= >> to return_to_command_loop. >> >> Now, if we return normally to a C++ caller with an error indication se= t, >> the C++ caller will almost certainly have enough stack space to throw >> its own exception and propagate the exception further. >=20 > 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 >> unwind_to_catch isn't really very different from the longmp to >> return_to_command_loop: I don't see any reason we can't run it on the >> alternate signal stack. In fact, I don't see why we can't replace >> return_to_command_loop generally with Fsignal. >=20 > See above: I think running arbitrary Lisp code on a 8KB stack is even > less safe that with C++ code. We avoid doing that for a good reason. > Let me remind you that Emacs on Windows sets up a 8MB stack (as > opposed to the standard 2MB) because it is necessary in some > situations, like matching some regexps. 8MB, not 8KB! A Lisp unwind > handler can do anything at all, so I think running the unwinding code > from a stack overflow is not an option, if we want to make sure stack > overflow recovery will not hit another fatal stack overflow in most > cases. >=20 >> I really don't like the stack overflow protection stuff in general >> though. It's not possible to robustly recover, because the stack >> overflow detection turns *any* function call into an operation that >> might return non-locally. In that environment --- where, say, XCAR mig= ht >> end up running lisp --- it's hard to maintain invariants. >=20 > It might be less than nice or elegant, but Emacs should give the user > an opportunity to save their work. >=20 >> I'd rather Emacs just die on C stack overflow, except when we know >> we're running Lisp in such a way that we know we can recover. >=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. We can gracefully recover from stack overflow of Lisp code. We cannot recover from stack oveflow at arbitrary points in the C core. --vklGpvokruXS0uJdMigusrNqwlgDg2GQA 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 iQIcBAEBCAAGBQJWebM+AAoJEN4WImmbpWBlnM0P/3FeV4yJBSWbM1TFJOxLI3zx fY++Q/5dy9IXW5SGCQakEStvIN2rrAnnFwfeHHvPuv689yA8cJGt/XVb5Z1qYhB5 QBhGYfCjoawi3QJ1SpiyG6zqVqa0gy1LdIzulpSUECZjgEYhIv/MLUqY+UcTcoQd INDoNDjbXjYh+YhoX9K3isIAC0EXqWDwZVZnScVuVL+vm+D9hhXcgoXLUkQGdPXd APPE2mE0WsXKno+3LdM7fvvJv0KdL9h3KQe8iYplj2PmK0HCqGDyivGdho0Q007x b72ekhE84dKFICaVvERBZR9XLkgHhyv+wbcR2EBGv3/jJ7w5hQ9SBewymVl6JOlC sjL5bUg4cwWKKjkyH2F4IsE/ozDv/k/Hl0TVEkM1Mlw2NyewcAZIAcNnBgYjOWE3 kHjZnkUMKk4rklZWe2O5MF14Wf9vH5dtpV6EaxqxuIQ626zWIk7ExY6qfX4pUpRc k7Laj4CtOa1vY+iTELXOPnHlNqzZFCPLpplj4SDgx8XJFG/fY7pedyD0+YZ2uTIT UzQ2eciPmm59o+ik/How7suRy45byMiKRQVG9OTrtKStneAPexAsdbxEfd4ZzXyM 9SIRgq+zVT/8NW+bzhbrV0D7UKcySkrZEVNskiUfjeN7aRF77v6FkDlysDr3Llwp LCAi4KjxP5n6UAhHPxM5 =9FW7 -----END PGP SIGNATURE----- --vklGpvokruXS0uJdMigusrNqwlgDg2GQA--