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: Two issues with stack overflow protection Date: Tue, 28 Jul 2015 22:01:55 -0700 Organization: UCLA Computer Science Department Message-ID: <55B85E43.6050306@cs.ucla.edu> References: <838ua0xkln.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020003090305070404070101" X-Trace: ger.gmane.org 1438146139 27157 80.91.229.3 (29 Jul 2015 05:02:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 05:02:19 +0000 (UTC) To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 07:02:09 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 1ZKJVJ-0001C5-1S for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 07:02:09 +0200 Original-Received: from localhost ([::1]:33365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKJVI-0001OJ-Ah for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 01:02:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKJVE-0001O9-U1 for emacs-devel@gnu.org; Wed, 29 Jul 2015 01:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKJVD-0006Im-R4 for emacs-devel@gnu.org; Wed, 29 Jul 2015 01:02:04 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKJVA-0006GC-0r; Wed, 29 Jul 2015 01:02:00 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id ACC1E160728; Tue, 28 Jul 2015 22:01:58 -0700 (PDT) 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 qr5FJBxK9Er3; Tue, 28 Jul 2015 22:01:56 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3FAA2160CB7; Tue, 28 Jul 2015 22:01:56 -0700 (PDT) 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 PuaoukBOJH9J; Tue, 28 Jul 2015 22:01:56 -0700 (PDT) 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 18641160728; Tue, 28 Jul 2015 22:01:56 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 In-Reply-To: <838ua0xkln.fsf@gnu.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:188158 Archived-At: This is a multi-part message in MIME format. --------------020003090305070404070101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eli Zaretskii wrote: > The implementation of stack_overflow on sysdep.c was recently changed > so as not to use sys/resource.h and getrlimit, but configure.ac still > insists on these two features in order to include the recovery code, > which I think should be fixed. Thanks, fixed with the attached patch. > More importantly, the recovery simply longjmps to command_loop, > whereas similar features like Fthrow and Fsignal do much more in > unwind_to_catch. Shouldn't stack overflow recovery do that as well? > Otherwise, the specpdl stack, byte_stack_list, lisp_eval_depth > etc. all stay at their values they had at stack overflow time, no? No, they are cleared back to top-level values, because when command_loop's call to sigsetjmp returns nonzero, it then calls init_eval and this resets them. There is a problem that the speclpdl stack's unwind-protect and dynamic-let-bindings are unceremoniously discarded on stack overflow. I suppose that should get fixed, though it may be a bit tricky to avoid looping. --------------020003090305070404070101 Content-Type: text/x-diff; name="0001-Remove-unnecessary-stack-overflow-dependency.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Remove-unnecessary-stack-overflow-dependency.patch" >From 2377572a880400182cd370c5ca104c7151e0f20c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 Jul 2015 21:41:59 -0700 Subject: [PATCH] Remove unnecessary stack overflow dependency * configure.ac (HAVE_STACK_OVERFLOW_HANDLING): Don't worry about $ac_cv_header_sys_resource_h and $ac_cv_func_getrlimit, as they're no longer needed for this. Problem reported by Eli Zaretskii in: http://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00443.html --- configure.ac | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 19b8b9d..45008d8 100644 --- a/configure.ac +++ b/configure.ac @@ -4557,9 +4557,7 @@ if test $emacs_cv_func_sigsetjmp = yes; then fi # We need all of these features to handle C stack overflows. -if test "$ac_cv_header_sys_resource_h" = "yes" && - test "$ac_cv_func_getrlimit" = "yes" && - test "$emacs_cv_func_sigsetjmp" = "yes" && +if test "$emacs_cv_func_sigsetjmp" = "yes" && test "$emacs_cv_alternate_stack" = yes; then AC_DEFINE([HAVE_STACK_OVERFLOW_HANDLING], 1, [Define to 1 if C stack overflow can be handled in some cases.]) -- 2.1.0 --------------020003090305070404070101--