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: Sun, 3 Jan 2016 06:27:34 -0800 Message-ID: <56892FD6.8040708@dancol.org> References: <83mvu1x6t3.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> <567C25B1.3020101@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vLs62Pkcxo6UOV8mHKpLnWcrPo2l1o7ru" X-Trace: ger.gmane.org 1451831279 18292 80.91.229.3 (3 Jan 2016 14:27:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 14:27:59 +0000 (UTC) To: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 15:27:49 2016 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 1aFjdM-0002zO-TM for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 15:27:49 +0100 Original-Received: from localhost ([::1]:41775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFjdL-0000dn-Ta for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 09:27:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFjdH-0000dY-6P for Emacs-devel@gnu.org; Sun, 03 Jan 2016 09:27:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFjdE-0006Lg-0d for Emacs-devel@gnu.org; Sun, 03 Jan 2016 09:27:43 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:37581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFjdD-0006Lc-LP; Sun, 03 Jan 2016 09:27: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:References:To:Subject; bh=ie+zlThhO7iPKr8RBlwE3f4OJtFQn9pzrb/qefQHJlw=; b=K4w0uN14ChHd1Mkycuhy87layvMTFeQdb2qdIbNSQxsqePGmubKbgsmpa5FUZwz97ONwmai4fRNqPZ+SwRsdruSev5NyyYmU47MBh2NfqcUoc9KW4wpE4r7y/SntzzH0RslpEQ/49crID7aiYzL084l6QY83kuDwdfbviZD8U++qmPWl1YkTogtaGw2qzxX4N5I3nA51vgSSE0sqhPFF/vtDiMG6BpjzZMapFoDVw/LX7S4zlFYBKpwJ0vVBoXRNl/yvHLmFtRXuClc5bVHw+z8qfBmfYddYHg8ug7oNjkce5d7ngd31p61UpJNJv+iy+zwNbl19LAmNYlCpSYUs/Q==; 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 1aFjdC-00058A-KP; Sun, 03 Jan 2016 06:27: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: 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:197442 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vLs62Pkcxo6UOV8mHKpLnWcrPo2l1o7ru Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/24/2015 09:17 AM, John Wiegley wrote: >>>>>> Daniel Colascione writes: >=20 >> 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 ove= rflow. >> You have not addressed the point that we already have robust stack ove= rflow >> 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 stac= k >> overflow is a problem worth solving. >=20 > Would someone be willing to summarize where we're at at this point with= this > discussion? It has been long and large enough that I'm no longer clear = on > exactly what it is that we do and don't want, and why. Just a summary o= f our > major alternatives at this point, and the most significant points for a= nd > against each would be great. >=20 If the C stack in Emacs overflows, Emacs crashes and terminates. Normally, we prevent C stack overflow by preventing Lisp evaluation from getting too deep by bounding it with the variables max-lisp-eval-depth and max-specpdl-size, but a nasty C function can still overflow the stack and crash. In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to detect C stack oerflow and longjmp back to toplevel. It's important to note that we don't just longjmp when we're in a safe position: we longjmp from *anywhere*, even if we're, say, in the middle of malloc. This longjmp can corrupt internal state in Emacs or libc, cause deadlocks, bypass C++ destructors in module code, or literally cause any behavior whatsoever, since we're violating invariants of the system. The longjmp also bypasses unwind-protect handlers and other kinds of resource cleanup. Everyone acknowledges that this path is very unsafe. Eli and Paul believe that "Emacs should never crash", and that potentially saving user data is worth the risk of undefined behavior, which they contend does not occur in practice. They are wrong. This code is terrible and that we should delete it immediately. The code is fundamentally flawed and cannot be made to work properly on any platform. No other program attempts to recover from stack overflow this way. (I surveyed a few in a previous messages.) In practice, the Lisp stack depth limits provide enough protection, and the risk of data corruption is too great. The existing auto-save logic is good enough for data recovery, especially if we run the sigsegv handler on the alternate signal stack (which we can make as large as we want) when possible. C stack overflow is a programing error just as bad as *((char*)1)=3D2 and= we shouldn't try to recover from it, *especially* not when this recovery is dangerous and leads to more problems than it solves. If we keep this code in Emacs, it sets a precedent for other terrible forms of crash recovery, like silently ignoring writes to NULL, replacing reads from NULL with zero, longjmping out of SIGABRT, and so on. If we believe "Emacs should never crash", we should fix its bugs, not try to paper over them with undefined behavior. --vLs62Pkcxo6UOV8mHKpLnWcrPo2l1o7ru 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 iQIcBAEBCAAGBQJWiS/WAAoJEN4WImmbpWBluZAP/2UR/7oWKNC9pSoOnFe50Rzp +6ya4PqYPz8y74gLD9NDhBz5QCa8XNncvEJosDIOhIN4oCCTtpwrf6J3i7/O+V6Y osFo3JnIp4RLPnfI00zkvZiMn2utvKgpGcQI6c8/wAt6yqEcmG3B4yKmVkuqChPa 50lWgBUtyYPExY+kpdC7YwkMmeG0CgGBAFeVSjjKUO98ccuVAM+3oohmIXLWVlQj r2A3tarAfV4A2DMPx5gbkDEWmBMVRArkAQWfB9/gtC1JbGwe4T8qkBWVjUxIq8nZ 8mwNKwOtNm1yCjRiDnyRvQ92tEZcxvk22avWr4lThn7bq2N8JhJfnQtu8E0UvtQ4 csbpC+uvhBeHpREiuMwtBjegH7JOi+SV1S4W3BmtHvga/n3t5swpsMqLeP06GJeH mS6Q+5lNsLPGsfoPnVnX6nA/klp4gVW0epAoWFgZFIn60OdjN6cR6lLtmeZsEviN MR5QFDRc9MxnzosNcnlCvbq+EJDmcNYvlayf1rOxSjsYh89sbZeZJtFzglIkYWRY NZmymBINaFE3LxOh9zPrz7SQDIOMA3HbGXjEWuD6UpmPAgz6ccMvU8NdMgklvafN Gtt8Zop8h7HOQVzg7atEr/H4qkFj/71oUu7w4fK+b07eqq/WY4p1HmAaBjRbs+02 C54FN4OWLMu40ryIASsE =wE7v -----END PGP SIGNATURE----- --vLs62Pkcxo6UOV8mHKpLnWcrPo2l1o7ru--