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: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.) Date: Wed, 23 Dec 2015 19:26:25 -0800 Message-ID: <567B65E1.6090809@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> <83oadiqxq1.fsf@gnu.org> <5679B33E.9000804@dancol.org> <83y4cmp5y5.fsf@gnu.org> <5679B7F5.9030504@dancol.org> <83twnap4xa.fsf@gnu.org> <5679BE1D.5070903@dancol.org> <83poxxp2rl.fsf@gnu.org> <567ACB0F.9060804@dancol.org> <83a8p1oyxc.fsf@gnu.org> <567ADCC0.6090709@dancol.org> <8360zpoxru.fsf@gnu.org> <567AE04F.1010202@dancol.org> <8337utox4o.fsf@gnu.org> <567AE5A3.7010902@dancol.org> <83twn9ngwc.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="HbGHLu48xUqBsd1tT2gjr6j6E8iHutaXG" X-Trace: ger.gmane.org 1450927615 15094 80.91.229.3 (24 Dec 2015 03:26:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 03:26:55 +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 Thu Dec 24 04:26:53 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 1aBwYG-0001QJ-KK for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 04:26:52 +0100 Original-Received: from localhost ([::1]:58729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwYF-00078W-Rr for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 22:26:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwXy-00075p-1T for emacs-devel@gnu.org; Wed, 23 Dec 2015 22:26:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBwXx-0000t3-0y for emacs-devel@gnu.org; Wed, 23 Dec 2015 22:26:33 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:41540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwXw-0000sz-Lx; Wed, 23 Dec 2015 22:26:32 -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=jctF8eBqjqcE1N3QKDKC+Q6bWoHMpEMnPSJSKoocwJI=; b=Wk7T8H+PhsAZ8jx9dLu8/fjBOKryOQrZW/hjb8HS3AM6ZPX04IUfP90ocH2kwvVGVXwPm82zVd0no8UjaY1lCsvrOLUlgr9YjtpVKTrwT8rn8fRf2/FDLTrfv2iFR6G4plopaTb/fVxrSCYJlZSEy0yXVcMjes/IuT7Ro3jf423iLxmaiiFWzjaDDrXa0SA6j2WTOnoDjzPSoeAlGhXkGjIGM/vCaH12Q6Q6WJdHUdn8KZOMFx5naRMuxUofzn/rukrK4sm6qkHEX/4+XHmyhf0jy8H1rnIGqh0I5gq4Bp80+SaYzgVLWms/pHyGdZcamls7qg04CV9U6KsK3hkZIQ==; 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 1aBwXv-0000G8-G5; Wed, 23 Dec 2015 19:26:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83twn9ngwc.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:196748 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HbGHLu48xUqBsd1tT2gjr6j6E8iHutaXG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/23/2015 10:45 AM, 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: Wed, 23 Dec 2015 10:19:15 -0800 >> >>>>>> We can make the alternate signal stack as large as we want. >>>>> >>>>> Not as large as is safe to run arbitrary Lisp. >>>> >>>> Then don't run arbitrary lisp after we've segfaulted. >>> >>> It's out of your control. >> >> No it isn't. We don't have to run the generic auto-save logic: in fact= , >> we probably shouldn't run arbitrary lisp, because a fatal signal >> indicates that the process is in a bad state. Instead, if we really wa= nt >> to minimize the possibility of data loss, we should use a pure-C >> autosave system directly from the crash handler, not longjmp from >> arbitrary parts of the program to toplevel. >=20 > auto-save is implemented in C anyway. But it calls functions that > might call Lisp out of your control. We attempt to disable that when > in emergency shutdown, but it's not bullet-proof. >=20 > And there still is a problem of buffers that don't visit files. So make it bullet-proof and very dumb: add a bit of C code that visits all buffers and writes their contents to a file we've pre-opened (so we have a file descriptor handy). On the next startup, read that file and restore the buffers. I don't think that measure is necessary though, since we already deal with stack overflow of Lisp in other ways. What convinces you that stack overflow of C code is a real problem? >> The other option is to use a guard page: on stack overflow, unprotect >> the guard page (allowing program execution to proceed normally for a >> little while longer --- again, no longjmp), Fsignal at the next >> opportunity to QUIT, invoke out_of_memory after the signal, and let >> users save at that point. >=20 > The guard page is too small for any serious code. It depends on how many of them you want to have. After all, until they're used, they consume only address space. (That's true on Windows as well.) >> Regardless, the current mechanism does not achieve its goal. >=20 > Of course, it does. It does not. --HbGHLu48xUqBsd1tT2gjr6j6E8iHutaXG 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 iQIcBAEBCAAGBQJWe2XhAAoJEN4WImmbpWBle9EP/1PXPRpVz1hJs8lF9f/SmfNn LRp0ETbh1FmHbrjr6ZtsMyrr7RVuKIHEqz04UkxEb/GEdr3kDfScsHjKapPfTiO/ La5dO9NtQG62zcbVyPBHZ96IblODlPawkRwt6IjFQCuHjn3Kuk9wmRNQeOiHAkDB Ajx7gE1iyNOygGUM9s7BCuJ+yg0ezR5AKIKPDHjDlLyuaEKOtNDvosG+MCo+JuUR dTcMkpHLKB/54i5AMhLQ34uHRaLCcmqxLeYu+cjipmCuz2kEYztlbMNsLUdPuhWD BZZ9TMJYWpVlPFemrAVQKnG3rK2oU51rWoEo91I9WAxZlIsaWZaLME3uIpjyxgit Og/wRyg0c6n4dpJtDT7x3NsXT0XoJ9jrcMPpderCL5GJcsIHeGADWiOr74cimrsH tuY81QM3fDsT9/ZSrABhUHbAuEtehwdMssPLAGHra4FRAg7mOf7CRUJNCw1TxmxQ yC94fTRnjZn1lT0Cvh/6v4UsY3wGafnU2TPBIdP8HjcZQHEuoMJVxLN4E4Xar8Kx QLKgraj2Dr9dgKTs7LXYPMztUKbR5gzUEtlwL58xS+Sva5fJ441MBoIcv6Hjhgm2 /4SqWUGQ0HKJx3ufFdUJPqSfPyHkgsK+dS9l4OllODaqJyeCcMmjKMDD1P9U1ol1 x1WkqfcmcmyHvZSuvHtm =QGJ/ -----END PGP SIGNATURE----- --HbGHLu48xUqBsd1tT2gjr6j6E8iHutaXG--