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: Mon, 21 Dec 2015 20:38:07 -0800 Message-ID: <5678D3AF.7030101@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Fxv6gH6fwFC0wF763OMT8KFuOvlmNBAgh" X-Trace: ger.gmane.org 1450759129 12716 80.91.229.3 (22 Dec 2015 04:38:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 04:38:49 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 05:38:36 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 1aBEiX-0005Ur-8i for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 05:38:33 +0100 Original-Received: from localhost ([::1]:48680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBEiW-0006rD-2I for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 23:38:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBEiG-0006r1-7H for emacs-devel@gnu.org; Mon, 21 Dec 2015 23:38:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBEiD-0006tc-1F for emacs-devel@gnu.org; Mon, 21 Dec 2015 23:38:16 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBEiC-0006tR-M8; Mon, 21 Dec 2015 23:38:12 -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=ibFnqXFyX+1ATK9rRQ73U3vw4Xs6nKvmqER7/YmwyyI=; b=pTSGI4rnqAfDV+rIwS9QR6e8CRx3Y+135rQa+AdK+Lqg9nqjUhs+F7xx3UODe5SMcMvo5+fgLOg1ZzGO6ksSMxs9fw6MMQzTDw0aNv5MsTDxKP/HhuKduwuNtEyh7CiMp/lz0zi9p7j4LX8pV2TOpiYiyM5S8GgjBsP5LmAYozqlm3zrbTanxZsbxjBR6/8GXBu6EvYYBk5n0XrHJyPbZuhr+PYwUOcBdcZrwe4+mpQxZ49Mh8jQb/kukas4r+x9DVTF7jw8Mr7t7zwCrlEPrixKkfgAapnldfKrOaY6HNmO+E2Gm0QrxgbTl4VWoCPBqSflcS3ssQGcrbL2YXnlUA==; 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 1aBEiA-0003sf-Pi; Mon, 21 Dec 2015 20:38:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <5678CD07.8080209@cs.ucla.edu> 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:196639 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fxv6gH6fwFC0wF763OMT8KFuOvlmNBAgh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/21/2015 08:09 PM, Paul Eggert wrote: > Daniel Colascione wrote: >> we should treat OOM exactly like other sorts of error. > > Perhaps we should, but currently stack overflow is not treated that way= =2E > >> OS signals should go through the usual Emacs event loop, right? > > I'm not sure what you mean, but let's put it this way: stack overflow > can occur while in the low-level handler for an OS signal. And even if > stack overflow does not occur, if the user types C-g three times when > inhibit-quit is nil, the OS signal won't go through the Emacs event > loop; instead, Emacs will invoke (signal 'quit nil). > > Perhaps what we need to do is to have stack overflow invoke (signal > 'stack-overflow nil), or something like that. It's a bit tricky, though= , > as one needs some stack space to call 'signal'. > >> The standard requires runtimes reserve enough memory to throw >> std::bad_alloc. All Emacs has to do is make sure control flow reaches >> the C++ level. > > How does this actually work, when combined with Emacs's C-level stack > overflow checking? Won't one get in the way of the other? Let's start over. 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 stack, 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 this 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 set, the C++ caller will almost certainly have enough stack space to throw its own exception and propagate the exception further. The only real change we have to make is to have Emacs longjmp not to return_to_command_loop (which might skip module frames), but to longjmp instead to the most deeply nested entry point from module code into Emacs, which we can set up in advance whenever a module calls into the Emacs API. 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. 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 might end up running lisp --- it's hard to maintain invariants. 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. (The bad_alloc comment is moe about exhausting the heap: even if we instead exhaust the malloc heap instead of the stack, we'll have still set aside enough space to throw a bad_alloc as long as Emacs returns control to C++.) --Fxv6gH6fwFC0wF763OMT8KFuOvlmNBAgh 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 iQIcBAEBCAAGBQJWeNOvAAoJEN4WImmbpWBlzyUP+wejTR9aMITAtFxL/1S0beLM NUd/xJvFW6NwRN+3P8bmArQ6VrzdBLdstRffTz4q5tVsm6aXSBxaaBgOjp12McXa gdMVH3mYHVI3dVjUkqoc78jNiTy7mqDptgm4L4+5Sknfco911Kxlimca24syaIwQ bn+KwaAoBKTzn0dbOmu6VZ1ZApO+4SBW7Qa8C3Qz1YKWLAxTn6at39C93oMApTG2 33ptvPJbXoXMedTHYl92VV9pURKa8cZoFdqiDAsMS0ZKPvutHXX1pjvAybQL9XIN rtIVT+GN6JW8wDawcSd2pnNYuHdz65/mS3HvHJmc1gRwPef2G3fbWRszmsx2IOFk aoc3g5K04neRfbSIDhgpDbnP8ZaK3jkdH6Y7wzDsO2/u/UzElnHC1sJbzA49vIAK 7NmaLvAip8NDCAeoKbjPf/mBgLXq7w1bCu+FrIxkPHm5jFsZMvjkYycxVyZjFWie OS29BOKxCx25Qjj1/BL9fBSCAiy0m0QmECtgasTnQKYKScFSedNXvfO6777pTXZt PKDKIo76t5N5ttRVBp2Y2Wjve2iV2q4SSQ0uMbl+D3347xWzgyODLsbZ+silj68u +qkR2VP1LrsO9gUd+OZYH+cIAgMQ7D2ADEQqWpODhgqXWX+Y/UtAZ3waMqV0/TVv AHgsV6L0yQix9SbjbEgT =tYWJ -----END PGP SIGNATURE----- --Fxv6gH6fwFC0wF763OMT8KFuOvlmNBAgh--