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 13:18:21 -0800 Message-ID: <5679BE1D.5070903@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> <5679B33E.9000804@dancol.org> <83y4cmp5y5.fsf@gnu.org> <5679B7F5.9030504@dancol.org> <83twnap4xa.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="h8U75r93qEbrHRKAeHJUrAmFaFx6hxoF7" X-Trace: ger.gmane.org 1450819163 21220 80.91.229.3 (22 Dec 2015 21:19:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 21:19:23 +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 22:19:20 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 1aBUKv-0000WG-Ea for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 22:19:13 +0100 Original-Received: from localhost ([::1]:53045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUKu-0006SU-Tw for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 16:19:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUKN-0005ZS-P5 for emacs-devel@gnu.org; Tue, 22 Dec 2015 16:18:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBUKM-0003Vh-CS for emacs-devel@gnu.org; Tue, 22 Dec 2015 16:18:39 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:60166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUKL-0003VW-SH; Tue, 22 Dec 2015 16:18:38 -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=4hj4pnFP/WkqPFkELXtD12wAVRFheM8zTehthCzI6uY=; b=FYRYJqy5N94QSGxmeSkgVPi1r+3wECvDYbyu+ecNG4ft+Yyrc1TBKr0KpG9MVTbsVWDiTb+k7EL5n19iYiV3iDovwvMBp91KuViEbap4fmbLfhUM+QBb+LgY8A/oTnvRJlNsFwEr9fYE1SkMPAe7h4O1la4WY4um3XUd8okO2xev8U939UOnpQOh3LgWdSOpQ4YFPtuy2mRG3ccuva1EQ00hcmSbviA6oMj3tQHYcwZoTGRCqpWlEjHAh3RXqSXuwWDaTOWEUHqK8VFkkxWbTY7rp8d+rjFpicMHVFRm0Dr/trV7zDNaV1EBiFOQF3Gg8OTuIaXR5CFsJOp5lAcx2g==; Original-Received: from [2620:10d:c090:180::d628] (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 1aBUKK-0000Dc-FU; Tue, 22 Dec 2015 13:18:36 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83twnap4xa.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:196693 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h8U75r93qEbrHRKAeHJUrAmFaFx6hxoF7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/22/2015 01:08 PM, Eli Zaretskii wrote: >> Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com, >> p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Tue, 22 Dec 2015 12:52:05 -0800 >> >>> If you only longjmp a short while, you have no idea how much stack yo= u >>> freed. You might as well be just 200 bytes below the level where the= >>> stack overflow hit. >> >> Which is why you setjmp in places where you have a significant stack >> reserve. > > There's no way of doing that portably, or even non-portably on many > platforms. You simply don't _know_ how much stack is left. You can probe at program start and pre-allocate as much as is reasonable.= >>> No, the core isn't in a bad state. Longjmp is not an abnormal path, >>> its semantics is very simple and clear. >> >> Longjmp, by itself, is simple and clear. What's unreliable is longjmpi= ng >> to Lisp at completely arbitrary points in the program, even ones marke= d >> "GC can't happen here" and the like. > > We longjmp to a particular place, not arbitrary place. But we longjmp _from_ anywhere, and "anywhere" might be in the middle of any delicate code sequence, since the compiler can generate code to write to new stack slots at any point. >> You say Emacs shouldn't crash. Fine. We can't make that guarantee >> if the crash recovery code breaks program invariants. > > Crash recovery doesn't need to keep invariants. Or maybe I > misunderstand what invariants do you have in mind. Any stack allocation anywhere in the program can longjmp. It's impossible to reason about safety in that situation. > >> If you want to longjmp, you need to do it at certain well-defined >> points only. The current approach is a bug machine. > > No, it isn't. There's a small number of places (2?) to which we > jump. That's all. > >>>> We can gracefully recover from stack overflow of Lisp code. We >>>> cannot recover from stack oveflow at arbitrary points in the C core.= >>> >>> We can and we do. The recovery has only to be good enough to allow >>> saving your work and exiting. That's the only goal of that >>> protection: allow the user to exit normally, after saving their work.= >> >> I'd rather rely on autosaves. > > It's not reliable enough, because it happens relatively rarely. Doing > it much more frequently will be an annoyance with many buffers. And > then there are buffers that don't autosave, but the user might still > want to do something with them if she needs to abandon ship. > >> Failing that, we should allocate guard pages, unprotect the guard >> pages on overflow > > Thats what the OS is for. It would be wrong for us to start messing > with page protection etc. The exception caused by stack overflow > removes protection from the guard page to let you do something simple, > like run the exception handler -- are you suggesting we catch the > exception and mess with protection bits as well, i.e. replace one of > the core functions of a modern OS? All that because what we have now > is not elegant enough for us? Doesn't sound right to me. We have a program that has its own Lisp runtime, has its own memory allocation system, uses its own virtual filesystem access layer, and that brings itself back from the dead. We're well past replicating OS functionality. It's not a matter of elegance: it's a matter of correctness. The current scheme is unsafe. > >> and call out_of_memory so that it's obvious Emacs is in a bad >> state. This way, we don't have to longjmp out of arbitrary code >> sequences. > > There's no problem longjmping out of arbitrary code sequences. When > you debug a program, you do that all the time. In GDB, interrupting normal control flow is not part of standard debugging practice. Lisp-level debugging can return to toplevel from anywhere, but only between lisp form evaluations, and returning to toplevel still runs unwind-protect handlers. The longjmp on stack overflow does not. --h8U75r93qEbrHRKAeHJUrAmFaFx6hxoF7 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 iQIcBAEBCAAGBQJWeb4dAAoJEN4WImmbpWBlMywP/0z3MyQKEUl6K02MPRCtVaLV x1cDGGzKGhg3NoYzE/oP9B8IHPIJ2Do7KDikoR6XG/mWl7DSZOMd46ZYG/DXA2Ft r76gi02kxaKNHF2QEHpeuyALGtRZTSWukkpwHRWH5zabjyd9knP1W1IXVENkzJLx X7RfnS4Ge7NLzaNNbvd4oODvLK3Kni0RVrMZC/Nbhjb4rMqGQGMcF0sXVaqNES2J 8Ss1wfBiz4ka6rH222Roe6K9hbzb02M5/+QZhGKPKiqAz51q5T3FUqAgbay4uQW8 1413NArHpUX5wGgi8fOIQoy1smo+Rf9epxlHqi96kieXD9D3DCzw0JlDw1Ey7bcx t7oXmbgz8/YUfu6k6XVF2k10Y/BNELyeF0vRMsxZUEocuEMxBccehVG8smd7BVCg vtneilt62o5QEPElL6mbkWJV8JzuTt+vJZ969oHmblP8Dghi/nmhCgc6htA4ok8+ PYncemMdDKk4aOh3sdri5z70vg6cOOQ8YbJJ+vpAqGW4YGlibQHp8WSGea9Sqd4K OZXJbZWko9vW3OmSFVDlOtnRSSGH4MMA/gc6nPIgWlIXpu5qcGC1DWXI6PNa7AWT pBm7M3Az+t4+FxiGb2aENfNHd1exex5vmaGLrKJv2oAC57/+AG6JSUpbK92P2L5r 0pvaYSY5k9WpU+RU2tXw =vKd3 -----END PGP SIGNATURE----- --h8U75r93qEbrHRKAeHJUrAmFaFx6hxoF7--