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 11:26:26 -0800 Message-ID: <568975E2.5080206@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.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> <56894CE7.7090301@cs.ucla.edu> <8337uea8ix.fsf@gnu.org> <568958D8.5060505@dancol.org> <83ziwm8sv2.fsf@gnu.org> <56895F0F.3050904@dancol.org> <83wprq8riy.fsf@gnu.org> <5689675A.70500@dancol.org> <83twmu8pjj.fsf@gnu.org> <568970A8.8000305@dancol.org> <83poxi8oga.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fuPCu4idTlv8c0BaawqcppBnmrNB56wAH" X-Trace: ger.gmane.org 1451849224 19073 80.91.229.3 (3 Jan 2016 19:27:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 19:27:04 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 20:26:56 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 1aFoIm-0000Rc-69 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 20:26:52 +0100 Original-Received: from localhost ([::1]:42606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFoIl-0003yw-KX for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 14:26:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFoIW-0003yo-GJ for Emacs-devel@gnu.org; Sun, 03 Jan 2016 14:26:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFoIT-0001uK-94 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 14:26:36 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFoIS-0001tw-Ti; Sun, 03 Jan 2016 14:26:33 -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:Cc:References:To:Subject; bh=zmlvS5eH3Kv5AUNr6GHP5vTZ5K3MTAoTr1F0Xi2UIzM=; b=Ua+XwS+wubOblsO1IJ4IBnCbNvbviOKAVp+RH9yRVYSwiR9dIX1h6TCjeBTqVRsWwQ1thklRGtQVqHyfYAAZnfVebNTAYKjFGwfmZs0qHIV5UHQEEbxRsGtxLzMg0uJCQtE8C/hfWJ/FkfYpXGSu8/0F6VHUUg5jatE3VIoKhYXE2Kxwisod6Q/ZKaJeLP7zd47ZNgvGlspjf8c6N/cb2GvxBsER8LhlG9loJBsUXm0hhI1pA+g//rmk/c7TkjwgZyB/ExiUzfkbMZ/4hl5d247OiKLrAdvyw+rbsyMRn6nykozQv1QiaFB9Ez97n64fSLtMgoCtBWqMElIFF2IPfQ==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFoIR-0006hq-Sk; Sun, 03 Jan 2016 11:26:31 -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: <83poxi8oga.fsf@gnu.org> 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:197488 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fuPCu4idTlv8c0BaawqcppBnmrNB56wAH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 11:15 AM, Eli Zaretskii wrote: >> Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Sun, 3 Jan 2016 11:04:08 -0800 >> >>> Yes, it is. You would like us to crash rather than try recovering. >>> That is a very heavy price in Emacs. >> >> Why is it uniquely unacceptable in Emacs? Why do other programs that >> fill the same niche not employ this strategy? >=20 > Not many other programs run for so long and have so much precious data > for their users. Besides, who says there are no other programs that > do this? libsigsegv wasn't written as an academic exercise. Many other programs run as long. One example is the Linux kernel, which panics on stack overflow. >> Why do we not try to mitigate NULL pointer dereferences (to which >> all the same arguments apply)? >=20 > We do: we catch SIGSEGV and try to save what can be salvaged. Invoking auto-save after resetting SIGSEGV is a good application of that approach. (We should make sure that control flow can't leave the sigsegv handler.) What's dangerous is allowing Emacs to continue running after we've detected that it's entered a bad state. I'm not against installing a sigsegv handler: I'm against returning control flow to toplevel. >>>> My point isn't that memory leaks are disastrous. It's that the >>>> consequences of this code weren't given due consideration at the tim= e it >>>> was committed. >>> >>> You have absolutely no evidence that this wasn't considered. It's >>> factually incorrect. You don't have to know that it's incorrect, but= >>> I would expect you to give more credit to our collective knowledge an= d >>> experience than you evidently do. >> >> I searched the mailing list and saw no discussion of the points I >> raised. >=20 > Who said that considerations must be in public discussions? On the > contrary, I'd rather take the lack of discussions as an indication > that this was considered and no one saw any problem with it. The existence of consistent with both my view and widespread, sagacious approval. Given the concerns I raised, the more parsimonious explanation is that the code went in without review, because even if you and Paul are right, it's worth having a conversation about the dangers of the code, and AFAICT, there was none. >>>>> You are not objective, so you exaggerate the risks and dismiss the >>>>> benefits. >>>> >>>> I disagree that there *are* significant benefits. >>> >>> Of course, you do. Like I said: your bias affects your judgment. >> >> So does yours. >=20 > No, I acknowledge the risks. You don't acknowledge the benefits. The benefit is that returning control to toplevel allows the user to save data in buffers where autosave is not enabled. I think the benefit is slight. Autosave is the only mechanism that protects against other failure modes, like the OOM killer, NULL pointer dereferences, and sudden power loss. Consequently, I strongly suspect that any truly precious data is in autosave buffers and that this stack overflow mitigation in practice allows the recovery of nothing important. >>> It's not undefined behavior, not in practice. We know quite well wha= t >>> can and cannot happen. >> >> No you don't, because we can longjmp out of third-party code >=20 > FUD. What "third-party code"? Any code we use in Emacs has its > sources open for scrutiny. First of all, it's perfectly legal to update libc to a version that wasn't around for a particular Emacs release, and this libc (which is perfectly conforming under _legitimate_ API use) might have problems with the Emacs recovery scheme that we didn't and couldn't anticipate. Also, third-party libraries are generally written under the assumption that control isn't yanked form under them partway through delicate operations. I don't think it's reasonable to expect that every library Emacs uses be robust under this kind of abuse. >>> Anyway, saying that "unpleasant things can happen" _is_ FUD. I want >>> to see a single bug report about these unpleasant things happening in= >>> real use, then I'll start thinking whether I should reconsider. >> >> And I want to see a real bug report about the stack overflow we're >> trying to defend against. >=20 > We've been through that already: if stack overflow never happens, the > recovery code can never cause any problems. Given that stack overflow is rare, we won't get to test the scenario much. We should err on the side of making Emacs behave predictably instead of trying to recover using undefined behavior, because if the recovery causes problems, it'll be hard to tell. >> The failure mode here wouldn't be obvious either: Emacs could just >> silently crash, hang, or write a wrong byte or two to a file. >=20 > Neither of which is a disaster. Neither of which will produce a bug report blaming this code, so the lack of bug reports is not positive evidence that this code is harmless. >> You have no idea what might happen, which is especially concerning >> because Emacs is frequently an internet-facing network program parsing= >> untrusted data. >=20 > All I want is to take every measure to avoid losing work. Every other > problem was already there before stack-overflow recovery was added. I agree that we should avoid losing work. The way to do that is to beef up autosave so that after a crash, we can recover quickly. That's the approach other long-running programs with precious user data, like Office, Visual Studio, Firefox, and vim, use. --fuPCu4idTlv8c0BaawqcppBnmrNB56wAH 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 iQIcBAEBCAAGBQJWiXXiAAoJEN4WImmbpWBl+YYP/18DO1cw6nDJv7zo3wB5GIBv kPVyD/VTS+rl0H2pqh+PSp+ar3ESRQk/aMnGC8twpdAzypYPANoLOrQ/iFJLgbSS jF2R4vj09wQVv442ioNXlz8FpHxVyw+XnPM7KSfvoCV6vi8afppiKnfT+xQgJkCz ydtwu/zCD5KB7WuZQiqSN3RuNfJl4W9YXWdf5PhxLc8XtGJxXs/FuPVH9lBtNm/H wpCPrWs6wzbZamWsszc6WdWILTAVZZTGSslo3uZyhG00vChdgEfNeQGfRtnztVTG gd50x8nAFSD2xVWSnalrHG74Cm1wRdQOrS4lUNjEwndeqa0s5uX0V0jorpBTmy9Z 8OwHF+ksuV4p53JIa7mSVGlLwVxAL/f6pK6Sd5m+t9tmYKZZuLnACxcHgNrfE0lD 4hRfYcDwJN+P/ki181AQWrK8Urklr2A9my6R4biXJ1xNXSRvNVpSganHWoMnjiNB y0VXZKSruOYGfA2PSLj8/Ee88nwYblwKbbEGF5+MsgHH6vF+f60/AI1EgnRJH0W3 FC6jgtO+pqNbLoLzYg94F3oak+ECOFUyB04nZXw4R+3DZGcfNtuqA5DRsmbW9HPs vQ9GfkdwpAo95QKRdnC9LRlfMLVA4JnQftre5Ic5woNmoMYPFNpnFEGA7mCQ7mLZ Fzo+0a5EFapfHQI75WHV =To+O -----END PGP SIGNATURE----- --fuPCu4idTlv8c0BaawqcppBnmrNB56wAH--