From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Crash recovery strategies (was: Dynamic modules: MODULE_HANDLE_SIGNALS etc.) Date: Sun, 03 Jan 2016 14:43:13 -0800 Message-ID: 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; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1451861027 25106 80.91.229.3 (3 Jan 2016 22:43:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 22:43:47 +0000 (UTC) Cc: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 23:43:40 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 1aFrND-0006a8-Od for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 23:43:40 +0100 Original-Received: from localhost ([::1]:43114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrNC-0006zB-VE for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 17:43:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrMz-0006z4-Na for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:43:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFrMu-00079z-Rd for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:43:25 -0500 Original-Received: from mail-pa0-x235.google.com ([2607:f8b0:400e:c03::235]:34605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrMu-00079t-Jn; Sun, 03 Jan 2016 17:43:20 -0500 Original-Received: by mail-pa0-x235.google.com with SMTP id uo6so167019117pac.1; Sun, 03 Jan 2016 14:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=mxuzqk5V6glPnlmdk5s/Gm5ozwAoQeTWqw4DaLHMKWE=; b=HWMYwAe5GOzL5LPb5qREOerNMXUM34RLLoQzQgz5fSvtTYFn1E+tYAIDkTs09KkKvi s/jfNXqMVHk5hP2IAICW+t6Ftiibd1I64WPkgp7oxAPtmC7EiugL5idjp4fxuDFK21HQ UauvrilWH72u0WM28XaXRkG0od1bVd7QOLYCpn16Cb9Qfn/oGZYq8R5DYvnxUdzTRFzE 1fC4DS23RZ9Qa5XcEQ30io0evGs+fgQvEF4oM8yljG0iz0GVe8L3B6/zRvfsb70oDhdn FWqAX5ZpvUfy12Ozo0chJvel95gW1wxlt2EA+s29fKBAJko9VJWk3GRqJrlneM0QPRhF yz+w== X-Received: by 10.67.6.233 with SMTP id cx9mr61786546pad.54.1451860999931; Sun, 03 Jan 2016 14:43:19 -0800 (PST) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id cf6sm17182923pad.41.2016.01.03.14.43.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 03 Jan 2016 14:43:18 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id 60DAC1200DED6; Sun, 3 Jan 2016 14:43:17 -0800 (PST) In-Reply-To: <56899EAC.1030408@dancol.org> (Daniel Colascione's message of "Sun, 3 Jan 2016 14:20:28 -0800") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin) Mail-Followup-To: Daniel Colascione , Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c03::235 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:197514 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Daniel Colascione writes: > Are you worried about startup time or correctness? Either way, wouldn't > wouldn't spawning a new emacs with -Q solve the problem? Except that it wouldn't be configured to use the right mail sender. :( > That's a reasonable UI, but popping up a window or otherwise displaying UI > in-process might not work. Instead, we can fork and exec a new Emacs to > interact with the user, and read from a pipe that process inherits a byte > telling the crashing Emacs what it should do. All that's perfectly legal = to > do from an async-signal-unsafe context. I'm OK if sometimes it just doesn't work. The new async Emacs idea sounds l= ike it has a host of unforeseen complications waiting behind it. > If we had real data, I'd be more comfortable with the feature. As it is, = we > have to rely on user reports, and I suspect that most users won't bother > reporting occasional hangs and crashes if it's any harder than pushing a > button. Given the absence of quantitative information, I'd rather avoid > undefined behavior. OK, your objection is duly noted. > That works. In particular, on startup, we can create a new, empty file un= der > ~/.emacs.d and keep a file descriptor to it open. Normally, we'll never > 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 elects = to > continue using Emacs or attach a debugger, fine. 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. > On next startup, for each crash file we find that isn't owned by a running > Emacs, we'll > 1) read and parse the crash file, > 2) prompt the user to send a bug report, and > 3) restore the contents of persisted buffers. > To avoid crash loops arising from certain arrangements of buffer contents, > we can restore each buffer in fundamental-mode, and with a name indicating > that it's recovered data. I like this idea. It's like Windows booting into safe mode, except it's safe buffers. > Of course, the downside is that the code to do this doesn't exist yet. 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. =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWiaQBAAoJEMFE2PTxn+YwNzwMALX3eiJN+zr2/H0UgeV8P4uF FKYfdhPgCR0JNa8AeYHyatrXuK+jf4MrKycB/m8SBAkERRj9tPmxvd2VqfgDMgk2 5UWgLBBOLsVgv9bB6dIpoXlpoyH8fWipfSRms8SpQU47ZDEcPBGOuybaYwcAukgt xZbPqRc3NoIaDuwF0Vgs5KVaA9+r27Ky9Db32SnYW8bKsiSGiJh45z/XfATIiT6x ZVflwZ44sKElEKTtkpKAFugsARQszo+rDlhTCCfE1Jcq7QHkN0Bq4WgdxAvKQCp9 6WfmrLm10qQlrB6yfzMubVsx5sRmrMSTn5kFKHXUrXqY8IxnUBvJoZ0d2gTV9tf9 ufv0yya6QDGGRE4KXq58Y8lZRz/WfVJGlBxfmCRV8e8uYuMHXlEodnOZprbo47e5 jNjP2namRcpju07ArqEpcMi0djtkAolJq4xy7mjtevS/CDjuAIFKFOYf140mYdkr z/kY90EVCQOORXLqB/dt/ecR5A/JmOVdSGufGm7UaQ== =qSVu -----END PGP SIGNATURE----- --=-=-=--