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: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 03 Jan 2016 13:07:33 -0800 Message-ID: References: <83mvu1x6t3.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.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> 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 1451855351 8619 80.91.229.3 (3 Jan 2016 21:09:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 21:09:11 +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 22:09:03 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 1aFptf-0007QL-9I for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 22:09:03 +0100 Original-Received: from localhost ([::1]:42938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpte-000145-JU for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 16:09:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFptZ-00011F-Jw for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:08:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFptW-0006jp-EP for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:08:57 -0500 Original-Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:35681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFptW-0006jl-7O; Sun, 03 Jan 2016 16:08:54 -0500 Original-Received: by mail-pa0-x233.google.com with SMTP id do7so1224640pab.2; Sun, 03 Jan 2016 13:08:54 -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=ztGQScj7ejnH5i0fRGf3Sd7Bpombc1QYOl/OyYfN4v8=; b=09nWjzOEWEQ9h9X3KH8tCbLg89sLf8pf+EMBSbMAvy3zJXMiwfiXSR18R0c99TMNIn c6PHHNd2P0dHXsqwHlN9psWD3LosYBnnAHQ9bDUy+5LKoIqDEvfMzgqZnGoxsFeUaCpf Nlm77ovzkya4WzDvkc8A+PjbzNlNrAEC1glXLDOil4xFm9OdPJzRJQoWPysg6XtEF+jK mWkmxsvbuzBVQVI+sbuxkQWNqfchc7kQnct+RyA6iYKvdf6IaxkIsZ4e00qz+yaWdCX3 hzoKxCDLhKKsPewCINILYRAkD5SxNzwa3QP9tvvVZC96bCQUtTWtrrue//Fg/kiZN7mm zD3w== X-Received: by 10.66.180.48 with SMTP id dl16mr120652306pac.39.1451855333692; Sun, 03 Jan 2016 13:08:53 -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 q82sm68140237pfq.1.2016.01.03.13.08.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 03 Jan 2016 13:08:52 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id CD01312000A2E; Sun, 3 Jan 2016 13:08:51 -0800 (PST) In-Reply-To: <568988EE.3010205@dancol.org> (Daniel Colascione's message of "Sun, 3 Jan 2016 12:47:42 -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::233 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:197503 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Daniel Colascione writes: > It's not just a theoretical problem: I've spent lots of late nights stari= ng > at stack traces, trying to figure out how a certain deadlock could be > possible, only to realize that the program had already crashed --- or wou= ld > have, if a seldom-tested bit of code hadn't checked for NULL and returned > without releasing a lock, causing a hang half an hour later. I see. Isn't what you describe an argument against error handling in genera= l, though? It too can mask the origin of serious problems. What if we do this: 1. When a serious error occurs that engages crash recovery, we pop up a window in Emacs describing that a serious error occurred that would ha= ve crashed Emacs --and that *nothing* should be trusted now. All the user should do is save critical buffers and exit immediately. 2. When in such a state, M-x report-emacs-bug automatically includes a tr= ace for the location where the crash occurred. Of course, this assumes Ema= cs is still functional enough to send e-mail. > You're right that under Linux, programs need to prepare for the possibili= ty > that they might suddenly cease to exist. We're talking about something > different here, which is the possibility that a program can *keep running= *, > but in a damaged and undefined state. I was thinking the system itself is now running in a damaged and undefined state. When that happens, I often reboot since I can't really trust it anymore. > I'm worried that it'll be hard to know if it bites us, particularly since > the problems I'm imagining are infrequent, unreproducible, and carry no > obvious signature that would show up in a user crash report. If we use a window to pop up an alarm indicating, boldly, that Emacs is now UNSTABLE and should only be used to save files and exit -- maybe even noting how to abort Emacs to avoid typical cleanup actions -- we can start getting feedback on whether this feature really helps or hurts. I understand error handlers can mask problems, and that they've made your l= ife more difficult as an engineer concerned with uncovering such causes. Howeve= r, I'm disinclined to accept, a priori, that it will hurt before trying it out. When Emacs isn't being run under gdb (which it almost never is) it also doesn't give much useful information about what happened, and loses data. W= ith the crash recovery logic, we should at least be able to provide a trace of where we were when the crash was detected, plus give the user a chance of reporting that data back to us. I see this as possibly *increasing* the amo= unt of error information we receive, and not just masking or eliminating it. =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----- iQGcBAEBCgAGBQJWiY2VAAoJEMFE2PTxn+Ywl9UMAIcGPboAnLFwFn3uyLL9PKUZ udouKn9N+mHXIif/8LOqLYw5jvN1mU6/EhZmR+D5myDXvFZBf8Z12t7qYwHQhrBT ym4VN+AKnz2p4Wk/+IrHpqVy+wt6KIWXAbP6ZdXgjqXO2X7CKL+xxkr/xU+JQULd XkOmjXiMR4f1Q+AsIxNwK0nt4+RcpNcH2TleQP3E52jRlJ9UFC3Trr8vRprG8Lx+ Ly2ZABPAUqzaUxBJiQ/LhApayLywgiSQAYzoJeGNx7u5P8fM+u2h02shVoMp3mgQ Q5TnrvSu+ySz4XdDv9j4M5v0a//S43XY6b/oX7koug0uygIu8pSvCUKyEd/0GZnS i3ftyNxwpKti/3JAJNgSmWT1k8Ks96cqRW67dmRRti0DQ8wKRNFAkty1tedozd2F ndRR3d7McKQ9akrRS/pFGw4jRJiAl8dDHzhFcAVAiM7S1BolUm+VdYI+rIdyTIqj QLhVP5Ry1akq06Vax4Ay0ouPrBfT1v0Y+IkAXNlBTw== =jxHQ -----END PGP SIGNATURE----- --=-=-=--