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: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 3 Jan 2016 14:20:28 -0800 Message-ID: <56899EAC.1030408@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ro08l6Xf5dLe7Q0bpKFEnko0mbjHEAUSD" X-Trace: ger.gmane.org 1451859654 6282 80.91.229.3 (3 Jan 2016 22:20:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 22:20:54 +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:20:53 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 1aFr1A-0001IB-Iu for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 23:20:52 +0100 Original-Received: from localhost ([::1]:43081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFr19-0002Av-QR for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 17:20:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFr0v-0002Ak-Pr for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:20:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFr0u-0003LA-Cd for Emacs-devel@gnu.org; Sun, 03 Jan 2016 17:20:37 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFr0u-0003L3-1s; Sun, 03 Jan 2016 17:20:36 -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=WpL1FFe5+N8Z0gOPn0n6UDKxxxOwdLFKXTR3ipv/mcE=; b=GZX7bF3bKzP4dMhr2AzeZJN1ohKY4g86MhZBnahOvGg4L4j/y1drEQmvGYv8fpASNwLENYPAIFT/4zIp5jB9lEPCoe1pWa9UOcicu06SAUy5F8jjlThMQfbwnnrCfbdMWyH9hhqYYauA0LxzQu3LtXNA9cwz2h3ocWWR0+m+0d/4ELolZzMpVw+OlAalnpAq7cajpLtMqnqRmJG5xY+v3B4Y3w1u64RQW2lqe6Xl8WsqE2kXMq9Ln/Y/HbKHPrzF7y/rvdymPNamrOYp+p6RGbXJN1OaTB0XMxnyFjrfJUUKuiF02QXE1xInGWXLoW45cdfJzKXq+S4sSE6k4P6dfA==; Original-Received: from [2620:10d:c090:180::1:692e] (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 1aFr0s-0007ck-VJ; Sun, 03 Jan 2016 14:20:35 -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: 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:197512 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ro08l6Xf5dLe7Q0bpKFEnko0mbjHEAUSD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 01:45 PM, John Wiegley wrote: >>>>>> Daniel Colascione writes: >=20 >> Ideally, Emacs would, on crash (and after auto-save), spawn a copy of = itself >> with an error report pre-filled. Fork and exec work perfectly fine in = signal >> handlers. >=20 > One problem here is that some of us have extensive configurations that = load a > great deal of saved state between executions. Spawning a new Emacs just= to > send an error report is not something I'd want to see happen. Are you worried about startup time or correctness? Either way, wouldn't wouldn't spawning a new emacs with -Q solve the problem? >> But in any case, if we put Emacs into a state where the only thing a u= ser >> can do is save files, why not just save the files? There's no guarante= e that >> after a crash that we can even display something. >=20 > So, on a detected crash, auto-save all files, and save a text file with= the > crash data before exiting? That sounds pretty safe and reasonable to me= =2E I'm imagining more a minidump than a text file, yes, that's the basic ide= a. > Maybe we could even popup a window to alert the user, and prompt them t= o press > a key, but the only action will be to exit (unless the user is a power = user > and uses recursive edit to attempt to interact with their now-broken Em= acs). 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. The new Emacs has to know *how* to display a message. I think it should be possible to look at the current frame's window system information. For NS and Win32, we just need to know whether it's GUI or a tty. For X11, we'd just need to extract display. On every frame switch, we can record this information in a simple variable we can read in any async-signal-safe way. Of course the child Emacs has to display something to the user somehow, but we can record the current window-system parameters on every frame switch into async-signal-safe state (say, a global char buffer), so that we can launch the child Emacs with the right display parameters. If the user indicates via the new process that she wants to continue using the broken Emacs, great. We should support doing just that. It'd be nice also to give that child Emacs support for attaching GDB to its parent, actually. Of course it's possible to attach GDB manually, but why not make it convenient? >> We have no information on how often Emacs crashes in the hands or real= users >> or how it crashes. A wait-and-see approach is just blind faith. >=20 > I prefer to think of it as data gathering. Accepting the words of one p= erson > about what the future will look like is more in line with the faith app= roach. > I'm not hearing a chorus of voices against this feature, and I have the= word > of other seasoned engineers in support of it. >=20 >> One question that neither you, nor Eli, nor Paul have answered is why = we >> would try to recover from stack overflow and not NULL deferences. Exac= tly >> the same arguments apply to both situations. >=20 > Why must it be all or nothing? Some is better than nothing. The error h= andler > can evolve after we know just how useful it is (or whether it is). 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. > Eli, Paul: What do you think about just auto-saving as much as possible= , > writing an error trace to a file, and prompting the user to press a key= , after > which we abort the running Emacs? This is in line with what many of my = OS X > applications do when they encounter a fatal error; they're kind enough = to tell > me that it happened, and give me an "OK" button to click before they ab= ort, > but they don't allow me to continue to operate the application in an un= known > state. 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 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. If not, we'll save to the file we've already opened information about the crash, followed by the contents of dirty buffers. 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. The advantage of using this scheme instead of the generic auto-save is that this one is async-signal-safe (and never runs Lisp), can't fail (except due to disk space exhaustion and the Emacs process disappearing --- because we've preallocated all other resources), works for non-file-backed buffers that wouldn't ordinarily be autosaved, and makes state restoration explicit. It also works perfectly well for crashes in module code. Of course, the downside is that the code to do this doesn't exist yet. --Ro08l6Xf5dLe7Q0bpKFEnko0mbjHEAUSD 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 iQIcBAEBCAAGBQJWiZ6tAAoJEN4WImmbpWBluasP/iVLnvTVRd3z4/SB71KYoFJR 4+PM6vx6Id0f9LrQdnN+2kqh3ehTtAMZOSI4m1CWbXR/BEeswTf6E8fhnxzE6Fsh GXieHHzEXTZc/X9eqxUBUc1yAPTqqZFdC51RWHmbZk97ZbzWaxB9coBmJRe22y2F GPQbbbbalukE3mYkTeHUGrN+afMD4NPDb58X8ckWXyIrG7wc5r8XdY0/8oT2rtKt Os6QGILbir1yaGeI8qGG7DATEIWYJ+O0skuX6DkAQFNBOkdb5v/LTgRxpCbnvTHz bAm4QDz+AhENchlMTZLjSJ3tPnZkZJtjDWJXqZTVC3usB990Rf4Sf3bMtUHJOXd8 EqCeTWW2IfiioO6KG7UiaZpkEGZQOJB9UMn2qfzNQakcCJLrl4aJ/jD89VxkCcUA zKq4mSSs+TB9SGrWMRlru1ojEaRQalyunx/5U0YNhfoNicIzIlo7d297Dw5i6he3 2TUokPpyPFEyFEMIxhXFtouIa80FforNda2YMmMZq6vXyOHnFkFtbcNeQBwvkEBB QO5fDVrfEZXrC32wUJ/HtC2tU/EG/tm5M+gSY7nqfBFiXKYPo1oh0F8MI1i7ipk6 ZKwDHNhTOaizBJi0+Sazl2VhXz8Ii1EzJFwW29RKIvGHReHUrD81yXhEigTfOKGu jD+C5qULwBfOqqVZDatK =pu2P -----END PGP SIGNATURE----- --Ro08l6Xf5dLe7Q0bpKFEnko0mbjHEAUSD--