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: Tue, 22 Dec 2015 18:12:07 +0200 Message-ID: <83io3qqx7s.fsf@gnu.org> References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <83io4nuc68.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.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> <5678D710.9010406@dancol.org> <5678E8FE.1010502@cs.ucla.edu> <5678EA4E.6080606@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450800714 12412 80.91.229.3 (22 Dec 2015 16:11:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 16:11:54 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, eggert@cs.ucla.edu, tzz@lifelogs.com, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 17:11:53 2015 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 1aBPXU-0002mw-TS for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 17:11:53 +0100 Original-Received: from localhost ([::1]:51388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPXU-0001Aa-7S for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 11:11:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPXH-0001AK-9F for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:11:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBPXC-0004zU-T3 for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:11:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPXC-0004zQ-PT; Tue, 22 Dec 2015 11:11:34 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1547 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBPXB-0002Yv-0g; Tue, 22 Dec 2015 11:11:33 -0500 In-reply-to: <5678EA4E.6080606@dancol.org> (message from Daniel Colascione on Mon, 21 Dec 2015 22:14:38 -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:196669 Archived-At: > Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com, > emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 21 Dec 2015 22:14:38 -0800 > > And even if it were OK for (say) 'cat' to dump core due to > > stack overflow in a typical environment (which it's not), Emacs is more > > important than 'cat', because people use it as an interactive text > > editor and do not want to lose their work. > > > >> we already crash if we overflow the stack while we're GCing. > > > > If so, that's a bug that should get fixed. It's not an excuse to > > introduce similar bugs. > > > > Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs > > should not crash. > > Ideally, we wouldn't have bugs. But we do, and when we hit them, we > should crash reliably and deterministically if we can't recover > reliably. I'm sorry, Daniel, but that kind of philosophy is a non-starter with Emacs. Saving the user's work even in some cases is much better than not saving it at all. And the current scheme is quite reliable, it works in many scenarios, though not all of them. As for bugs that cause fatal errors, Emacs always tried to catch them and at least auto-save. This also doesn't work with 100% reliability, but it saved me my work many times in the past. It would be a step backward to give up that, just because it's not bullet-proof. IOW, crashing reliably is an anti-thesis for Emacs, has been for as long as I can remember. And for very good reasons, IMO. We are not going to change that. > The current stack overflow scheme can't recover reliably because it > doesn't fix maintain invariants. There are ways to fix it --- e.g., > we can make our own guard pages, mark them PROT_NONE, and on stack > overflow, mark them PROT_READ | PROT_WRITE long enough to reach > eval, *then* signal, but I don't think it's worth it. Improvements to the current recovery are welcome, although what you suggest might run afoul of constant changes in the OS internals, so it could be fragile (or perhaps even impossible on some systems). Still, if you have patches to propose, please do, and thanks. Bottom line, I mostly agree with Paul: we should keep the stack overflow recovery. We should also try improving it as much as possible, in particular wrt modules. However, I don't think letting modules run arbitrary stack unwinders, let alone Lisp handlers, when we detect a stack overflow is a good idea, because the alternate stack is too small for that, and will run higher risk defeating the recovery.