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 15:04:26 -0800 Message-ID: <5689A8FA.9040206@dancol.org> References: <83mvu1x6t3.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> <5689A6DE.2080709@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kg5kISXmxe0bW0eIGXS5k3OTNmr6mFO1v" X-Trace: ger.gmane.org 1451862287 10587 80.91.229.3 (3 Jan 2016 23:04:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 23:04:47 +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 Mon Jan 04 00:04:46 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 1aFrhb-0001US-AF for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 00:04:43 +0100 Original-Received: from localhost ([::1]:43169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrha-0003Y6-RA for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:04:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrhX-0003Xo-2N for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:04:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFrhV-0002Zz-UR for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:04:38 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrhV-0002Zq-Io; Sun, 03 Jan 2016 18:04:37 -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=gKKHDQBVYMQB2gFT5OSJC1SxOf+yhHMtxrrHlF0+XNY=; b=MKlhM85QBQ93MScw7AC9wtK6w5ovvx/+NUV4XegSoewUNfOSsxIGJ3ozHP8Xw2KX0m99P124tGJTdIvrQVCxB+OSykIqeGgnkiOsibrCdlJ0gdw7b5YGOcPOZ5AdE1oFPIQ85RZQAkhoQ6ZMGwJnqqughRN3w3K8e0kRZii/Bukq8ZUtFIdzEaNMpcSP/dkECLn2rjSCPPtsLanYWMTzimnXwIahYfOFhutpeLVWDXuMwTODRv+x2PTDGzqZiYJ1wdEmiU9Ll4Hqjyt9XsCub3iiN7i4B5EkcoazWsUjV/oByHpoPo8bL1/UW9MeeMRz7ZZQjLDoRTFSKzgKGLqISA==; 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 1aFrhU-0007qx-Qn; Sun, 03 Jan 2016 15:04: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:197519 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kg5kISXmxe0bW0eIGXS5k3OTNmr6mFO1v Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 02:59 PM, John Wiegley wrote: >>>>>> Daniel Colascione writes: >=20 >> But that the emacs -Q process won't be doing any sending. The next reg= ular >> Emacs process will do that. The process we spawn from the sigsegv hand= ler is >> just for asking the user what to do about the crash. If we can't launc= h the >> process, we can do the default thing, the right choice for which is pr= obably >> to write the crash file. >=20 > Hmm... something about this approach just doesn't feel right, but I'm n= ot sure > what it is that I don't like. I'll have to sleep on it. Fair enough. I don't think in core we've had any features that rely on Emacs re-executing itself. I've wanted to make the byte compiler do the same for years though, so it might be worth seeing how hard it would be to make this work. >>> I'm OK if sometimes it just doesn't work. The new async Emacs idea so= unds like >>> it has a host of unforeseen complications waiting behind it. >=20 >> 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. >=20 > This isn't going to be a 100% solution to any problem, so I'm OK if thi= s is a > scatter-gun approach. The problem is that displaying a GUI dialog box requires re-entering the main event loop, which I think risks too much undefined behavior. A separate process sidesteps the problem. >>>> On next startup, for each crash file we find that isn't owned by a r= unning >>>> 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 con= tents, >>>> we can restore each buffer in fundamental-mode, and with a name indi= cating >>>> that it's recovered data. >=20 >> If implementing a scheme like this is what it takes to kill the stack >> overflow code, I think I can implement it. >=20 > Wouldn't the stack overflow code still exist, to catch the error? Maybe= I > haven't understood something... Can you explain how this approach remov= es that > code? The code that bothers me is the code that longjmps *out* of the sigsegv handler that catches stack overflow. The handler being there is fine. Under my proposed scheme, we won't longjmp out of the handler unless the user tells us to do that. --kg5kISXmxe0bW0eIGXS5k3OTNmr6mFO1v 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 iQIbBAEBCAAGBQJWiaj6AAoJEN4WImmbpWBlGfgP+PKw7TCH20LPct0zOAkWEAvt SLhtNHwDW42EokCypbm0c+sJNWtpDdo/J5rPHkIKQgyvQ6oRRVAh85sFGonNAx6B 6dleODuYBfCtNTC0vIjsoGbYH5vAcBis7omEjDZ1u85w66Y23XO0Vep1z5a3EcpG yEYjBYR2d7QpyUZrZmWi4AlUO1NzTJs9vlP+6880v3QC1+vEYCZ9r9b99Oq5SZ3A 442787XZglEXhVmKc1ddbf4lpqEg0YMAKb5A92cm3VclJ5u6yT1034bAcqFQT2Xf IuWAP/XINI1x+FET6rhhdMTYYxTzovAC/2RdcxHDfe6g8ByrCNSxHbWcu8KYub4/ L+tHolyow5Mqml5JREbLjkzyox4OqKE71UQlUbAomaU+SVyyZHMNDwJzvf7A2O9/ +8rJuOQcIeTcuyY5yDJq0HKEyVzaMrjHSm8Kgxgzq30y3j6Q+Sw8Mj/6zyxuwHvV AMuoyTwuZ2cHmBq0T1e7bXGPYDz1beimHZk7jmrUUfeTnc+0H300Dxhb2+e4SjcS oeJ7WZ9IXMe8VI2YKVif8GHwQZoDGaGi2Airuk5VZXL2NIF+MyhePWg6cmKPNNTC sCCLM24FOfPPcbPukrAwlpwRJxfcmBtlJSzn4uaDqXCFlxb/4sRm9aaI/Tya34Qt gCNsXGMpKi0orPK7jTY= =egFl -----END PGP SIGNATURE----- --kg5kISXmxe0bW0eIGXS5k3OTNmr6mFO1v--