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:01:10 +0200 Message-ID: <83oadiqxq1.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450800077 2071 80.91.229.3 (22 Dec 2015 16:01:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 16:01:17 +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:01:08 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 1aBPN4-0002VJ-Ld for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 17:01:06 +0100 Original-Received: from localhost ([::1]:51343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPN4-0005KM-6D for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 11:01:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPMf-0005Jx-2X for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:00:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBPMb-0001Ub-Sg for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:00:41 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPMb-0001UX-P6; Tue, 22 Dec 2015 11:00:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1541 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBPMa-0002S5-QR; Tue, 22 Dec 2015 11:00:37 -0500 In-reply-to: <5678D3AF.7030101@dancol.org> (message from Daniel Colascione on Mon, 21 Dec 2015 20:38:07 -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:196666 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 20:38:07 -0800 > > Right now, when we get a SIGSEGV, we check the siginfo_t the OS gives us > by calling stack_overflow on it; if that returns true, we longjmp to > toplevel. We configure the sigsegv handler to run on an alternate stack, > so we'll always have space to do that much work. The longjmp restores > the original stack. On the other side of the longjmp, we resume > execution with our regular stack, but much further up the stack. At this > point, we know we have a stack overflow, because nothing else longjmps > to return_to_command_loop. > > Now, if we return normally to a C++ caller with an error indication set, > the C++ caller will almost certainly have enough stack space to throw > its own exception and propagate the exception further. 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. > unwind_to_catch isn't really very different from the longmp to > return_to_command_loop: I don't see any reason we can't run it on the > alternate signal stack. In fact, I don't see why we can't replace > return_to_command_loop generally with Fsignal. See above: I think running arbitrary Lisp code on a 8KB stack is even less safe that with C++ code. We avoid doing that for a good reason. Let me remind you that Emacs on Windows sets up a 8MB stack (as opposed to the standard 2MB) because it is necessary in some situations, like matching some regexps. 8MB, not 8KB! A Lisp unwind handler can do anything at all, so I think running the unwinding code from a stack overflow is not an option, if we want to make sure stack overflow recovery will not hit another fatal stack overflow in most cases. > I really don't like the stack overflow protection stuff in general > though. It's not possible to robustly recover, because the stack > overflow detection turns *any* function call into an operation that > might return non-locally. In that environment --- where, say, XCAR might > end up running lisp --- it's hard to maintain invariants. It might be less than nice or elegant, but Emacs should give the user an opportunity to save their work. > I'd rather Emacs just die on C stack overflow, except when we know > we're running Lisp in such a way that we know we can recover. 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.