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 09:41:20 -0800 Message-ID: <567ADCC0.6090709@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> <5679BE1D.5070903@dancol.org> <83poxxp2rl.fsf@gnu.org> <567ACB0F.9060804@dancol.org> <83a8p1oyxc.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="HoodKsjW6iDXHs0sHnQlc8K8Drfw2nlPI" X-Trace: ger.gmane.org 1450892534 21194 80.91.229.3 (23 Dec 2015 17:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 17:42:14 +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 Wed Dec 23 18:42:13 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 1aBnQQ-0008IP-J8 for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 18:42:10 +0100 Original-Received: from localhost ([::1]:57243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnQQ-0000aj-3q for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 12:42:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnPm-0008FY-0S for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:41:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBnPk-0000bQ-MG for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:41:29 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnPk-0000bD-AO; Wed, 23 Dec 2015 12:41:28 -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=JbNGsznCIZ1WqtWnb+UFjAtV1o+5+CyHQftVHHZ4/Ko=; b=g/6laY1vC1RqePRmucMeNz51iO6qy+eHlYCWAX2Uijg3uaEo5D8fEXaJ7wgFFpTXeAZYb1dH5pugOZ/3+c0VgArRf+XAbEXHyg3Dc6HgAU6tt6go6BHPA1SPLz2d1kBSmzR5kT5laJ25ognxLfI1iGOHLqYb+aLeihCMQynowdQTUtSs4UEWMw0nI2x/OgTCAAp91Bq60UevfzH+yMU/2TGo9Q9H8UzLzd//mydwhJ+wREtalmR6Q/5DBAojFTwvuy4RXnK+suZWt6W/qYk7oVVyAT6FU/+TxUPC6EuUndpy5xxQaJHNMqZSqbLSpdfg0AEg3WixSIEvyhsEHDya1g==; 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 1aBnPi-00060M-SU; Wed, 23 Dec 2015 09:41:26 -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: <83a8p1oyxc.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:196728 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HoodKsjW6iDXHs0sHnQlc8K8Drfw2nlPI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/23/2015 09:30 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 08:25:51 -0800 >> >> We can alloca, say, 8MB, and write to the start and end of the allocat= ed >> region. >=20 > How do you know the alloca won't trigger stack overflow? We don't know that, but at program startup, we have no data to lose. How do you know Emacs BSS requirements won't run the system out of memory? >> Then we'll know we have at least that much stack space available. >=20 > At that point, yes. But you need to know that at many other points, > when some of the stack is already used up. Sure. But now Emacs can ask itself, "do I have at least X KB of stack space available?", and if the answer is "no", signal if Y KB of stack is available (Y>> I simply don't see any trouble this could cause, except leaking some >>> memory. Can you describe in enough detail a single use case where >>> this could have any other adverse effects that we should care about >>> when recovering from stack overflow? >> >> What happens if we overflow inside malloc? One possibility is that we'= ll >> longjmp back to toplevel without releasing the heap lock, then deadloc= k >> the next time we try to allocate. >=20 > I very much doubt anything like that can happen. An malloc > implementation which behaves like that won't last long. Lots of C > programs longjmp from signal handlers, so interrupting malloc with, > say, SIGINT, must work. I think even Emacs did something like that in > the past, at least on a TTY, where C-g triggers SIGINT. These programs are all unsafe. If they work, it's by luck alone. In fact, it's not possible to write a malloc that behaves the way you'd like, since malloc can legitimately take locks, and the system provides no way to release them on non-local exit from a signal handler. You're essentially claiming that programs using pthread_mutex_lock won't last long. There are a few existence proofs here and there to the contrar= y. The problem isn't limited to locks. Malloc could be in the middle of updating internal data structures when you longjmp out of it. The next allocation could scribble over arbitrary memory. >>>> 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 O= S >>>> functionality. >>> >>> Actually, most of the above is simply untrue: we use system allocator= s >>> to allocate memory >> >> We have internal allocators for strings and conses and use the system >> allocator only for backing storage. >=20 > On some systems. Not on all of them. >=20 >> , and if by "bringing itself from the dead" you allude to >>> unexec, then what it does is a subset of what every linker does, >>> hardly an OS stuff. >> >> Granted, that's toolchain work, not "OS" work, but it's still outside >> the domain of most text editors. >=20 > Sure. But a linker is still an application that reads and writes > files. It doesn't futz with OS-level features like page protection > and processor exceptions. What's so scary about page protection? I've yet to see a coherent argument for why we shouldn't take advantage of the facility where it's available. >>> Emacs is not safety-critical software. It doesn't need to be "safe" >>> by your definition, if I understand it correctly. >> >> It's not safety-critical software, but undefined behavior is undefined= =2E >> What makes us confident that we can't corrupt buffer data by longjmpin= g >> from the wrong place? >=20 > Nothing makes us confident. Recovery from stack overflow is not > guaranteed to work in all cases. But if it works in some of them, it > is already better than always crashing, IMO. Why? If we can prevent data loss, I'd rather reliably crash than enter some frankenstate where anything can happen. >> Anything can happen because we can longjmp from anywhere. >=20 > Yes. But if we hit a stack overflow, we are already in deep trouble. And it's because we're in deep trouble that we should kill the program as quickly as possible. >> What if we just installed a SIGSEGV handler (or, on Windows, a vectore= d >> exception handler) that wrote buffer contents to a special file on a >> fatal signal, then allowed that fatal signal to propagate normally? >=20 > I presume you mean auto-save, not save. >=20 > We could try calling shut_down_emacs from the signal handler, but I'm > not sure if the small alternate stack will be enough for write-region. > Something to investigate, I guess. We can make the alternate signal stack as large as we want. >> The next time Emacs starts, we can restore the buffers we've saved >> this way and ask users to save them --- just like autosave, but done >> on-demand, at crash time, in C code, on the alternate signal stack. >=20 > Why "like autosave"? What will be different from actually > auto-saving? shut_down_emacs does that automatically. >=20 Er, yes, I noticed that after I wrote the email that we already do what I propose, more or less. In this case, we don't lose very much by just deleting the stack overflow code and relying on autosave. --HoodKsjW6iDXHs0sHnQlc8K8Drfw2nlPI 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 iQIcBAEBCAAGBQJWetzAAAoJEN4WImmbpWBl3GIQAJeDCiCn/McIYA0E8PWY82Ng bo8NcsLZorr2U6klVJAVAbsnshYFg1APFH5dDsakzQE036tDB2yIOT3Te1yVUUxt 6Cmy0vwtZJkCTtWdZxc2RmjbPuiOtFEsJyBtFMhc8QTyREoTtJeViKkrSFhXSqaJ lsjdtygCmKxcW83Z6a3NzbxGO0lK7YXS6heRkmLbtpS92iJf9bnX7kJ9W3ktf7P9 pSJFMG9V/8Pn7naX2uwgWfbT0ZtJzLVGYbSyn33Bu8g+uk5DQLpS7UdgRmFNPuI8 j3OH1zPzMabX4/1CCAmqE83Abmg9L3DDUvBVxSu1G3fClZ/3ux06kSIfehfDclhn 0s7qOA2fuoDRo9UvXjzYadlTfgSuIrCowIbzArkDVuREoqNgoGe3zGDpS00jMl5d QaFMSM9CWeLDnZF5CjNItBta7jRIN3xKena278genJUDoeUwkXlYmCqSj8NsKeVH LOP7cm+bTOyxStjPvgldCBT79AJEDHRk0Ksy+fVFWDn3Rw14uHZmP9tO4k6gmOhc JKc10BauX57FFirlcAUlZQFsERN3gV9mmaYNFTvz3Hosuz6IQjPkKV5CRbDPgTem 07/I/jIAcMf7xSCD1DbE+3YZO9uXmrvBspkbC5zNe8YImxf1pubqDch9+4i2CjEF /qWunhbr1Aeh9efQUlDv =+z7W -----END PGP SIGNATURE----- --HoodKsjW6iDXHs0sHnQlc8K8Drfw2nlPI--