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: Thu, 24 Dec 2015 09:04:49 -0800 Message-ID: <567C25B1.3020101@dancol.org> References: <83mvu1x6t3.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> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.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="aowdqgC2XHVAKXFvLEKSIxnA1CG49aE3T" X-Trace: ger.gmane.org 1450976722 28355 80.91.229.3 (24 Dec 2015 17:05:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 17:05:22 +0000 (UTC) Cc: Emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 24 18:05:14 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 1aC9KD-0005hG-DQ for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 18:05:13 +0100 Original-Received: from localhost ([::1]:32773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aC9KC-0005cf-IR for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 12:05:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aC9Jy-0005cU-9F for Emacs-devel@gnu.org; Thu, 24 Dec 2015 12:04:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aC9Ju-00049J-W9 for Emacs-devel@gnu.org; Thu, 24 Dec 2015 12:04:58 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aC9Ju-00049D-Kl; Thu, 24 Dec 2015 12:04:54 -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=Au3auujj5KmaO2brs2EUA/GJSXHcFH4KqouZH8Pn7J8=; b=hyPPoAa7adOHWRHSGkj4jBVzuLpw6yw2SWoNHShTwoSRKSCVhD2glspxyPcmBp0XGfJcnXUXuknJHnRLIfpWTD0OZeFIxJ3RAkubQFnOwZ3aizNkeB6ON9HFnmpDqK0AA70DRVcxTNYF+KZ6Ys0a/kVA12UHTeJFhCEimq/KDbs3kr2/fywg2sXhNm1umid8EfGK5h/n1zhxybnIF5vgusv1misKHHgN6N/O8nt/5AUvBq/D3XUoLppGjZv+LcDDe/cRVSfnAk3x/RFJQeC1dKa7g9eNmLPq+gkRNupxSluLYlgASgmIpaLFjRzq7nh51XwM32Y76CXaj62lCG5Ktg==; 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 1aC9Jt-00046s-Nd; Thu, 24 Dec 2015 09:04:53 -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: <83fuyromig.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:196771 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aowdqgC2XHVAKXFvLEKSIxnA1CG49aE3T Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/24/2015 08:10 AM, Eli Zaretskii wrote: >> From: Paul Eggert >> Date: Wed, 23 Dec 2015 18:51:23 -0800 >> Cc: Emacs Development >> >>> Please stop repeating the false idea that >>> longjmp from arbitrary points in the program to toplevel is harmless.= >> >> Neither Eli nor I have said it's harmless. Merely that it works well e= nough in=20 >> practice. Let's not make perfection the enemy of functionality. >=20 > Right. >=20 >> > the current mechanism does not achieve its goal. It's >> > utterly unsafe even without module code added to the mix. >> >> It's safe enough in practice. You're right that in *theory* it's utter= ly unsafe,=20 >> but Emacs is a practical program not a theoretical exercise. >> >> Really, the idea that we'll let Emacs crash on stack overflow (merely = because=20 >> modules are being used) is a non-starter. We need a better solution. >=20 > 100% agreement. >=20 You'd prefer Emacs to lock up or corrupt data instead? Neither you nor Paul have addressed any of the alternatives to this longjmp-from-anywhere behavior. You have not addressed the point that Emacs can crash fatally in numerous ways having nothing to do with stack overflow. You have not addressed the point that we already have robust stack overflow protection at the Lisp level, and so don't need additional workarounds at the C level. You have not even provided any evidence that C-level stack overflow is a problem worth solving. All I see is a insistence that we keep the longjmp hack stay because "Emacs must not crash", even though it demonstrably does crash in numerous exciting ways, and won't stop any time soon, because real programs always have bugs, and experience shows that failing quickly (trying to preserve data) is better than trying to limp along, because that just makes the situation worse. I know the rebuttal to that last point is that the perfect shouldn't be the enemy of the good: believe me, I've debugged enough crashes and hangs caused by well-intentioned crash recovery code to know that invoking undefined behavior to recover from a crash is far below "good" on the scale of things you can do to improve program reliability. There is a good reason that other programs --- not other text editors [1], not other VMs [2], not web browsers [3], not GCC [4], nor GDB [5] --- uses the completely unsafe mechanism Emacs currently uses to react to stack overflow. (If such programs exist, I haven't seen them.) Most programs, in fact, don't bother trying to recover from stack overflow, because most of the time, in practice, their stack use is bounded statically. Let me detail a *safe*, *effective* alternative one more time. If you really want to make lisp-induced stack overflow less likely, here is how you do it: 1) Using some mechanism (alloca will work, although OS-specific options exist), make sure you have X MB of address space dedicated to the main thread on startup. At this point, we cannot lose data, and failing to obtain this address space is both unlikely and as harmful as failing to obtain space for Emacs BSS. 2) Now we know the addresses of the top and bottom of the stack. 3) On each time Lisp calls into C, each time a module calls into the Emacs core, and on each QUIT, subtract the current stack pointer from the top of the stack. The result is a lower bound on the amount of stack space available. This computation is very cheap: it's one load from global storage or TLS and a subtract instruction. 4) If the amount of stack space available is less than some threshold, say Y, signal a stack exhaustion error. 5) Require that C code (modules included) do not use more than Y MB of stack space between QUITs or calls to the module API 6) Set Y to a reasonable figure like 4MB. Third-party libraries must already be able to run in bounded stack space because they're usually designed to run off the main thread, and on both Windows and POSIX systems, non-main thread stacks are sized on thread startup and cannot gr= ow. I have no idea why we would prefer the SIGSEGV trap approach to the scheme I just outlined. As a practical matter, modules will not adhere to weird Emacs-specific stack overflow detection schemes. Insisting on them will not help. If the current longjmp scheme remains in place, the user-visible behavior will be "Emacs randomly locks up, and the stack in the debugger is impossible according to the code as written", not "I was able to save my data". [1] vim (7.4.712) autosaves and exits on fatal signals, of which SIGSEGV is one. It uses an alternate signal stack to do it, just as I proposed in a previous message. [2] hotspot (openjdk-8-u845-b14) uses a guard page to generate StackOverflowError when Java code blows the stack, but if the overflowing frame is C code, it simply lets the program crash [3] Firefox 43 uses Breakpad to handle fatal errors (which we really should do too, but that's a separate discussion) [4] GCC (current master) turns SIGSEGV into an internal compilation error= [5] GDB (current master) just crashes on SIGSEGV, although it does have a special case for trying to catch crashes in the C++ name demangler functions --aowdqgC2XHVAKXFvLEKSIxnA1CG49aE3T 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 iQIcBAEBCAAGBQJWfCWxAAoJEN4WImmbpWBlXOwP/Rto+YuuvSCyYixgSVQw00PD DVufjq0HPcRwjXPXV847fMeA+XaJWemk/XUJlHIAmC5oFgToqLng8dvS+g2Z7QiE yWdCrrQKqUCB0LgfzBFsh9n7KPlEuFcTUbNuvFNFNKO+2/reGg4r1J0SVIqlS7yp wXWoSRwRwa/Z1hG0MnVlXCqlU0WrIS02tHQunzhuUOfNXuW7mFTORxK3Bb7POfxw 5Rc6swwyjZ1eJSGUkjCvUIR53nnNEaWJ4KIihtYMdvd4TcHuXKHOicZvAbBGL7gc T8s8otW0sQ0bpB6jwAKTefw6vJoXlR1WHB4fOhW5BXEf+QmEPkroCkRleVokdeIq yxazYPu4tHMXkNmNCWqkliiAV3qTUsD2T3+Z3nwkqxtYqBKw5TXP77p08Ezz9Ce0 qP8iiZUdbffNiD8eBNHVZqbsu7Na6z6r+DlBlwRLDhDBa947pqARgupAhYLohinL Y8rRM4QWUwcWkZA+ypcqiJkhcr2Mj1qBgshNm74CMhXrM+Yov7AZAmXYBLMGx7C9 TsdEAvzHJbrIQWKpi/THH4kZH0an+YAq0hgmK4a2YCBQm0QlXiae1aJIFRYLlW25 /ee6IoKGbhwp0UuWm2YPJGJRRahkihoAO1o1eDe8mE3hm7uf35Kj9vJw6Qp+tcBA YnLpj5lXgVvtAZPp2StB =9a+x -----END PGP SIGNATURE----- --aowdqgC2XHVAKXFvLEKSIxnA1CG49aE3T--