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 22:46:26 +0200 Message-ID: <83y4cmp5y5.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> <83oadiqxq1.fsf@gnu.org> <5679B33E.9000804@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450817175 22900 80.91.229.3 (22 Dec 2015 20:46:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 20:46:15 +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 21:46:10 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 1aBTow-0007tk-5R for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 21:46:10 +0100 Original-Received: from localhost ([::1]:52902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTov-0008EV-GZ for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 15:46:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBToj-0008ED-L9 for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:45:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBTog-0004xb-EN for emacs-devel@gnu.org; Tue, 22 Dec 2015 15:45:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTog-0004xV-Ba; Tue, 22 Dec 2015 15:45:54 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1828 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBTof-0006cx-CZ; Tue, 22 Dec 2015 15:45:53 -0500 In-reply-to: <5679B33E.9000804@dancol.org> (message from Daniel Colascione on Tue, 22 Dec 2015 12:31:58 -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:196690 Archived-At: > Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com, > p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 22 Dec 2015 12:31:58 -0800 > > > I very much doubt that. The alternate stack is quite small (AFAIK, > > the standard value that we are using, SIGSTKSZ, is something like > > 8KB). Running arbitrary C++ code on such a small stack is not safe. > > (My understanding is that the value of SIGSTKSZ should suffice for > > calling printf, and that's about it.) There will be high risk of > > hitting yet another stack overflow, this time a fatal one. > > We're not talking about running arbitrary C++ code on the small stack. > The longjmp transfers execution to the original stack, but with the > context popped off. > > Overflow stack: A B C D E F G > Signal stack: 1 2 3 longjmp > Resumption stack: A B C If you only longjmp a short while, you have no idea how much stack you freed. You might as well be just 200 bytes below the level where the stack overflow hit. That's why we jump to the lowest level we can: there, we _know_ we have enough stack to do any kind of stuff. > > You are in effect saying the stack overflow recovery code should not > > have been added to Emacs. But we already decided that an attempt to > > recover is a useful feature, and I see no reason to go back. Even if > > this is works only in some cases, partial recovery is better than a > > hard crash, because it lets users save their work. > > Or it actually corrupts their work, because the Emacs core is in a bad > state. No, the core isn't in a bad state. Longjmp is not an abnormal path, its semantics is very simple and clear. > We can gracefully recover from stack overflow of Lisp code. We > cannot recover from stack oveflow at arbitrary points in the C core. We can and we do. The recovery has only to be good enough to allow saving your work and exiting. That's the only goal of that protection: allow the user to exit normally, after saving their work.