From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 03 Jan 2016 19:16:06 +0200 Message-ID: <8337uea8ix.fsf@gnu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451841384 765 80.91.229.3 (3 Jan 2016 17:16:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 17:16:24 +0000 (UTC) Cc: dancol@dancol.org, Emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 18:16:17 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 1aFmGO-0001H1-6C for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:16:16 +0100 Original-Received: from localhost ([::1]:42358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmGN-0001LL-8e for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 12:16:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmGJ-0001LG-UJ for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:16:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFmGF-0000VT-B9 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:16:11 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmGF-0000VK-79; Sun, 03 Jan 2016 12:16:07 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2489 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aFmGE-0000SK-Ei; Sun, 03 Jan 2016 12:16:06 -0500 In-reply-to: <56894CE7.7090301@cs.ucla.edu> (message from Paul Eggert on Sun, 3 Jan 2016 08:31:35 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:197469 Archived-At: > From: Paul Eggert > Date: Sun, 3 Jan 2016 08:31:35 -0800 > > Daniel Colascione wrote: > > In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to > > detect C stack oerflow and longjmp back to toplevel. It's important to > > note that we don't just longjmp when we're in a safe position: we > > longjmp from *anywhere*, even if we're, say, in the middle of malloc. > > Although that particular code path may have been introduced recently, for > decades Emacs has longjmped from arbitrary locations due to other signals, so > adding a longjmp for SIGSEGV does not introduce new issues. > > > The code is fundamentally flawed and cannot be made to work > > properly on any platform. > > The code is part of Emacs 24.5 and does not appear to be causing problems; at > least, I don't recall any bug reports from the field. The other longjmps, which > are fundamentally flawed in the same way, have been in Emacs for decades, and > also seem to work well enough in practice. All true. But we are reiterating a long discussion, where all of this was already said, and said again, and again, and again. There's nothing new left to be said here. Daniel thinks that Emacs should be designed and implemented as safety-critical software, where any such techniques are a definite no-no. But Emacs is not a safety-critical program, it is allowed to crash from time to time, even in nasty ways. It is therefore okay for such a program to use techniques that make the probability of losing work lower. My analysis of this discussion is that this is the crucial point that Daniel refuses to understand and/or agree to -- that being a non safety-critical piece of software means Emacs can do stuff that it otherwise would have been prohibited from doing. IOW, a requirement as fundamental as safety-criticality _does_ affect the design and the techniques allowed during implementation. I submit that this is a fundamental software engineering issue which cannot be cast away, and as long as Daniel misinterprets it, we can never agree on anything. Because in safety-critical software, even a single nasty crash can be fatal, something that is very far from what Emacs can do. > One possible way forward here is the approach recommended by GNU libsigsegv. See > "About stack overflow handlers". In > the past we've avoided libsigsegv's approach because it was considered to be too > heavyweight, but it would be safer to do something along the lines that it > suggests, or perhaps even to use libsigsegv if available. Just for the record: the MS-Windows implementation of stack overflow recovery is a simplification of the Windows code in libsigsegv (the simplification is possible because libsigsegv, as a general-purpose library, allows more flexible stuff to be done in the handler). So at least on MS-Windows, we already do what libsigsegv does. > > If we keep this code in Emacs, it sets a precedent for other terrible > > forms of crash recovery, like silently ignoring writes to NULL ... > > Naah. We're pragmatic, not stupid. Indeed.