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 recovery strategies Date: Sun, 3 Jan 2016 14:55:26 -0800 Message-ID: <5689A6DE.2080709@dancol.org> References: <83mvu1x6t3.fsf@gnu.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> <56892FD6.8040708@dancol.org> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> <56899EAC.1030408@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i9xQim32Pjxtssc1hdtXnlBRVrfiDrHK1" X-Trace: ger.gmane.org 1451861758 3545 80.91.229.3 (3 Jan 2016 22:55:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 22:55:58 +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 23:55:57 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 1aFrZ5-0001bO-Um for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 23:55:56 +0100 Original-Received: from localhost ([::1]:43143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrZ5-0000DB-CX for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 17:55:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrYr-0000Cn-CL for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:55:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFrYq-0000wY-8K for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:55:41 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrYp-0000w8-UI; Sun, 03 Jan 2016 17:55:40 -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=DecStefrDEUFqWMBKHgFoFBwOMvwVvTu0m6cL8n9PSQ=; b=Byg+WTqJZDIkQPTvulYNfyiXS+ZlE+vWyIJ/zoXeTfAc+C6z6JrgCro6eRp3zdAUD2+SEEt5gfP58+QInLPGwN3uF4UqZ8WXo8bd3D1dmWeb+Jm9TtI55q119B+O4ilnyWgWbZglwZLyvbsWvblLTfee9aW2HrHwo7/EEDBOA5WvS9SrKPnH7X2LVVJgaMva12Z3GfJ01zZAYxW3vFezwsRPdeY5G8M9n2B0DH4ZOdMv5OhsajcHeMDcMXUX3onguXzwbr7vuADC1HvNOsbUJ4x+5DHGzXVRGnjI3hWOaJpgGkLRqgG+62DcYk4n62PmS8b6ylzaju/FfOSKU+E6KQ==; Original-Received: from [2620:10d:c092:180::1:6442] (helo=[IPv6:2620:10d:c0c1:1110::109b]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFrYn-0007n0-3F; Sun, 03 Jan 2016 14:55:37 -0800 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:197515 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i9xQim32Pjxtssc1hdtXnlBRVrfiDrHK1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 02:43 PM, John Wiegley wrote: >>>>>> Daniel Colascione writes: >=20 >> Are you worried about startup time or correctness? Either way, wouldn'= t >> wouldn't spawning a new emacs with -Q solve the problem? >=20 > Except that it wouldn't be configured to use the right mail sender. :( But that the emacs -Q process won't be doing any sending. The next regular Emacs process will do that. The process we spawn from the sigsegv handler is just for asking the user what to do about the crash. If we can't launch the process, we can do the default thing, the right choice for which is probably to write the crash file. >> That's a reasonable UI, but popping up a window or otherwise displayin= g UI >> in-process might not work. Instead, we can fork and exec a new Emacs t= o >> interact with the user, and read from a pipe that process inherits a b= yte >> telling the crashing Emacs what it should do. All that's perfectly leg= al to >> do from an async-signal-unsafe context. >=20 > I'm OK if sometimes it just doesn't work. The new async Emacs idea soun= ds like > it has a host of unforeseen complications waiting behind it. The problem is that we can't *tell* whether it doesn't work. If we try to do that, we can just silently not execute. >> If we had real data, I'd be more comfortable with the feature. As it i= s, we >> have to rely on user reports, and I suspect that most users won't both= er >> reporting occasional hangs and crashes if it's any harder than pushing= a >> button. Given the absence of quantitative information, I'd rather avoi= d >> undefined behavior. >=20 > OK, your objection is duly noted. >=20 >> That works. In particular, on startup, we can create a new, empty file= under >> ~/.emacs.d and keep a file descriptor to it open. Normally, we'll neve= r >> write to the file. If we see a crash of *any* sort, however --- stack >> overflow or some other bug --- we'll prompt the user. If the user elec= ts to >> continue using Emacs or attach a debugger, fine. >=20 > Ah, showing the report on the *next* Emacs invocation is also something= that > OS X applications do (as an example of prior art). I like that idea. >=20 >> On next startup, for each crash file we find that isn't owned by a run= ning >> Emacs, we'll >=20 >> 1) read and parse the crash file, >> 2) prompt the user to send a bug report, and >> 3) restore the contents of persisted buffers. >=20 >> To avoid crash loops arising from certain arrangements of buffer conte= nts, >> we can restore each buffer in fundamental-mode, and with a name indica= ting >> that it's recovered data. >=20 > I like this idea. It's like Windows booting into safe mode, except it's= safe > buffers. >=20 >> Of course, the downside is that the code to do this doesn't exist yet.= >=20 > I'd like to know what others think (maybe they are ignoring this thread= now, > so I've changed the subject). But I feel like there is some convergence= now. If implementing a scheme like this is what it takes to kill the stack overflow code, I think I can implement it. --i9xQim32Pjxtssc1hdtXnlBRVrfiDrHK1 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 iQIcBAEBCAAGBQJWiabeAAoJEN4WImmbpWBlff4P/3lwO504KeYY5ywXh615NyKf cPw17wqI6l2/XCuBMdb9pQiuL+iKGZbnrPS1DCuwLhk7UGsNl/qzDf0krCUuaMVm VAKad8/vN8XSC1Ys7+MQafJdS3pEq27W+tdXhukSV/FYk+BGyl9IkmEujTbG6wm1 pFCoHJwfPHB65EK65j92TykzbrR3fc1plepmvn23Joz0I912jMPd1zSDaUmj+DHs GrgrpaWy4ZuYdlWrnpd6jckMmLYEBNHxnwQMdi5W0XBGsGUYVyngaY/o4sZdU8c3 I74juFxaiPv07JkSopOQcm+VjAGe9bkiuJcdmo2fnF8AM1EmOZgm7y5LphIOuuzt jIARspn1gX6i4HjErvkYMquMR3tiu4ilkR+pPSZLrnA2zg+6Vm51KAQrFbrqYeZ6 LLswfE0dS9lhy6R4VpLsV6ertnn+TO4CFwOLvYKCDFmuNQjFs2Ae958C/brYuPpu cfdc4dnGlarfkV/RcHQaM4xKhGXV9VK0WVD0UzLIbJXE0wQl9DawKhFuA9iQLbPX zM4m8PLZFx3U7WGUVY5Ul5Ix6WCqu2kDnM8WgW9LJGh5J93Mo2LNplZhKNWzy0+1 61DS9JbHJxjGRlhhLu88DctpUJzNoCBpsgUbXgNeK3Wgcb1gIv53IweHV73i/jGK sXpHqtVP8slj6j7+5GTS =O0gD -----END PGP SIGNATURE----- --i9xQim32Pjxtssc1hdtXnlBRVrfiDrHK1--