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: Wed, 23 Dec 2015 09:18:30 -0800 Message-ID: <567AD766.3060608@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> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@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="DXJw8xEJvsce4Dfgt2hEBq53gIBpv9B1n" X-Trace: ger.gmane.org 1450891130 30887 80.91.229.3 (23 Dec 2015 17:18:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 17:18:50 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 23 18:18:48 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 1aBn3m-0004xA-RT for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 18:18:47 +0100 Original-Received: from localhost ([::1]:57153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBn3m-00083l-47 for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 12:18:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBn3h-000830-5z for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:18:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBn3f-0002YL-Li for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:18:41 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBn3f-0002Y7-At; Wed, 23 Dec 2015 12:18:39 -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=RctsycSS+uHoiRcWBaE4stoOhUAiSOlz3cY84+yqCj0=; b=neb+Bm22g1zIUpKDvqSuFk86eGog0SN1XP3DTw0eRbhcq1X5s/fQDZoZDlW2d2nM6q96KQBEVcYYshPeatN4+rhGoGhYGk4pcz/s65ln5Jzlmly84wlWHNMw2vfrVGV3hxoVT/29WjwwwqkCPE2o38JBHggBVndw5sOIO6Q4mIXAXsCBhDD5QqFLGG+pNQvWoUqV3AbtJTY4Sg+R0aOnxmYSSgKmG7aOVYXfUd2q4LIg9YETCru0hnxMsxY9cBBwYLE+WPt0K2itQos8l/wweSd0EUUc/gUz3l3Q4e/Axr2qLKmczK6N5o1womnG3YgKt4bF/iImkrc2BE5gkdLp+w==; Original-Received: from [2620:10d:c090:180::31bb] (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 1aBn3e-0005tT-JL; Wed, 23 Dec 2015 09:18:38 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <567AD556.6020202@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:196724 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DXJw8xEJvsce4Dfgt2hEBq53gIBpv9B1n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2015 09:09 AM, Paul Eggert wrote: > Philipp Stephani wrote: >>>> We could merely require that any module needing recursion must call = a >>> new stack-size-checking function at each level of recursion, in order= to >>> detect stack overflow. >>> >>> That's performance penalty. I don't think we should incur that, on >>> behalf of a problem that really should "never" happen. >>> >> >> It's also impossible. Modules will be written in arbitrary languages a= nd >> make use of arbitrary libraries, some of which might not even know abo= ut >> Emacs's existence. We cannot impose any constraints on module code. >=20 > There's also the issue that other languages may have their own > assumptions about how stack overflow is detected, assumptions that may > disagree with Emacs's method or even prevent Emacs's method with > working. My own preference also is to rely on the usual VM techniques > for ordinary C-code modules, and hope that other languages don't get in= > the way. Still, it may not be possible to do that, and we may be forced= > to impose a bit of software overflow-checking on modules implemented vi= a > recursion, for module authors who care about reliability. >=20 > Does anybody know how C++ and/or Java and/or Python modules detect and > recover from stack overflow on GNU/Linux? That would be a reasonable > sanity check here. (And if nobody knows, that's not a good sign....) Python uses explicit runtime checks, IIRC. HotSpot uses a guard page. C++ is just the C ABI and is indifferent to stack overflow. Most C-ABI programs treat stack overflow as another variety of fatal memory error, and I think that's the right approach. I don't see why Emacs needs to be special here. >>>> Also, any module with an unbounded amount of computation should call= >>>> the >>> equivalent of QUIT every now and then. If the module API doesn't let = (or >>> ideally, require) modules to do that now, it should. Otherwise it's a= n >>> Emacs freeze waiting to happen. >>> >>> I agree, but I think it's unrelated to stack overflow. (Though I >>> think we will need to have a module-specific version of QUIT, as long= >>> as we keep the constraint of not directly longjmping from module >>> code.) >>> >> >> There's no harm in providing such a functionality (but of course we ca= n't >> enforce its use). >=20 > We *could* enforce the use by requiring at least one call to QUIT every= > (say) 100 ms, and by doing the equivalent of 3x C-g when the time limit= > is exceeded. That'd be useful even without modules. That's grossly unacceptable. Individual page faults (over which programs have little control) can take longer than that. Besides, modifying all code to fit into Emacs' idiosyncratic model of stack overflow detection is unreasonable. Modules exist in large part to call into pre-existing, unmodified libraries. >> Even if we >> assume "benign UB" (which is dangerous because UB tends to become more= >> malign as compilers evolve), it will cause internal state to become >> inconsistent, which is truly disastrous. >=20 > Emacs has been relying on this sort of "benign UB" for years, in areas > just as disaster-prone as C++ cleanup, and it has worked well enough. I= > don't see why C++ would be any different. Typically C++ cleanup is just= > recovering memory, so we'll have a memory leak; big deal. Emacs is a monolith and has been written with non-local returns in mind. Most programs are not. The existing scheme is completely unsafe; you can do a lot worse than leak. Please stop repeating the false idea that longjmp from arbitrary points in the program to toplevel is harmless. >=20 >> handle_sigsegv already has several cases where the longjmp is skipped:= >> when >> in a GC, when the signal is received from the wrong thread, and when i= t's >> not guaranteed to be a SO. In those cases Emacs aborts (still >> autosaving). >=20 > 1. You're right about the GC, but that aspect of GC is considered to be= > a bug (it's called "hard GC error" in the handle_sigsegv comment) and > should not be precedent for us installing similar bugs elsewhere. >=20 > 2. The wrong-thread check is because we are attempting to detect stack > overflow only within Emacs (which can occur due to a user program error= , > which should not crash Emacs); stack-overflow errors in other threads > are considered to be internal errors in Emacs and indeed never should > happen, so it's OK to treat them as fatal errors (I expect this should > be true even if the other threads were created by a module). >=20 >> Why can't we do the same if SO is detected while a module function is >> active? >=20 > It might be reasonable to do that if the stack overflow were entirely > due to the module -- that'd be like stack overflow in some other thread= > created by the module. But it would not work when Lisp code almost > overflows the stack, then calls the module code, which overflows; in > this case Emacs needs to recover rather than aborting. The _only_ thing Emacs can safely do is abort. The right approach is to make sure aborting minimizes data loss. There is no reason for Emacs to be more concerned than other programs about this rare error case. --DXJw8xEJvsce4Dfgt2hEBq53gIBpv9B1n 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 iQIcBAEBCAAGBQJWetdmAAoJEN4WImmbpWBlE0AP/j1Z1UM8HXLPp164ArsSnWIb O8o7lLqxnEAh0NL7qsGiqyWEZnfSJ2X0+Px2UHT+kOWdujP/cwJzDro7wJn6L4MY iEF4qWK08bthvraVSqnsZ1wVuR5eFchb+4rEJpZoZhw0z2gsvHCmXMu9uoRh7t0W TDUFDVS/EbfL+xDE5oSE1H5Qap9SGGaizCsN/5EPQY6YZquLZ1TrdH+IfFfg5QgV EOkEtYtMOgH5I8tg0OkDxGsvPgPmj/WEyjEfVPoUpDdOXlxkzNkSY/Rj6NugpoLV NM0rBKTrUsgyCLfa7gaMUoKvFksz7Y4BzCxWMTCkcL99Yeq/OLNqpIv1i26Y6Hh6 GLGuVaS9lDyeFURuUVt/UzQzGWnJ/fSe3TwJpZI3qT5T/Z9G5rDaJZzsAho6fgyx 2lmu5PEKevBMCNqhhD6igMlad5BjAf08IhPFabBr41N7FJQ7g68zEuY/NYPhuVrs upVbzC4S31+TPfUzpzCFxlkH0HR3kHyTfxTDwhTqeBitVWrIP/B+1zwXA4PlBpJ4 w+2VeDFE0LOTLgLyQpeN1j8nEZVxZ5VRK4ZWPl2hcM9ZSTNeW8jFeekS1JY4d24B rbJywkEbNF2rXuyDAbELeOUhUZTpOCeJ3RUYxpaLgn1uNYx0TXbixPRlD/0w0hLm Bxgv6MxEksXpqyEXe3ps =4fBC -----END PGP SIGNATURE----- --DXJw8xEJvsce4Dfgt2hEBq53gIBpv9B1n--