From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 3 Jan 2016 13:02:39 -0800 Organization: UCLA Computer Science Department Message-ID: <56898C6F.4010303@cs.ucla.edu> 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> <568950C5.2030306@dancol.org> <56896359.4020309@cs.ucla.edu> <568966D4.5080707@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1451854982 3530 80.91.229.3 (3 Jan 2016 21:03:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 21:03:02 +0000 (UTC) To: Daniel Colascione , Eli Zaretskii , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 22:02:54 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 1aFpnh-0001J5-ME for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 22:02:53 +0100 Original-Received: from localhost ([::1]:42925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpnd-0007X8-G9 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 16:02:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpna-0007Wv-10 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:02:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFpnW-0005nu-Rn for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:02:45 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpnW-0005nq-Iy; Sun, 03 Jan 2016 16:02:42 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E843F1607C4; Sun, 3 Jan 2016 13:02:40 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d0FWpp_jrSUZ; Sun, 3 Jan 2016 13:02:40 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 27580160817; Sun, 3 Jan 2016 13:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bxY4USYp8jr6; Sun, 3 Jan 2016 13:02:40 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 017861607C4; Sun, 3 Jan 2016 13:02:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <568966D4.5080707@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:197502 Archived-At: Daniel Colascione wrote: > neither you nor Eli have demonstrated in any way that all this > complexity is necessary, that we actually have a C stack overflow > problem, I mentioned (1) stack overflow in the regexp code, and (2) stack overflow in C modules; did you miss that? The counterargument for (2) that C modules can crash Emacs in countless ways so let's not worry about stack overflow is not all that convincing. It can be useful for the suspenders of stack-overflow checking to go along with the belt of must-be-perfect modules. > handle_interrupt can call quit_throw_to_read_char only > when waiting_for_input is true, which it is only when, well, we're > waiting for input, not at arbitrary points in the program. Ah, good point, so that part of the code should be OK. Still, a few lines earlier we see things like Fdo_auto_save () and fflush (stdout) that can be executed from a Unix signal handler while quit-flag is non-nil. Although this has undefined behavior too, this code has been around for quite some time and I use it more often than I like to admit. > Or can we use a stack guard region [1], and in the signal handler, > unprotect the set a global variable in the signal handler, and check the > variable on QUIT, and at toplevel, reprotect the guard region. If we > segfault again without having reached toplevel, just die. Would that > make you happy? I think something along that lines would suffice, yes. Admittedly I didn't quite follow what you wrote (perhaps some text got elided?). But the main point, as I understand it, is that we needn't worry about having a stack-overflow check inside the stack-overflow handler, because we can insist that the stack-overflow handler be tightly-enough controlled so that it won't recurse indefinitely.