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: Avoid C stack overflow Date: Thu, 13 Mar 2014 10:57:33 -0700 Organization: UCLA Computer Science Department Message-ID: <5321F18D.5080008@cs.ucla.edu> References: <5321E00C.2010107@yandex.ru> 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 1394733471 17487 80.91.229.3 (13 Mar 2014 17:57:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Mar 2014 17:57:51 +0000 (UTC) To: Dmitry Antipov , Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 13 18:57:58 2014 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 1WO9tD-0000RF-73 for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2014 18:57:55 +0100 Original-Received: from localhost ([::1]:40944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO9tC-00061E-QW for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2014 13:57:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO9t2-0005wU-TZ for emacs-devel@gnu.org; Thu, 13 Mar 2014 13:57:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WO9st-0003LP-OT for emacs-devel@gnu.org; Thu, 13 Mar 2014 13:57:44 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:58924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO9st-0003KM-Iv for emacs-devel@gnu.org; Thu, 13 Mar 2014 13:57:35 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 4FC9E39E8019; Thu, 13 Mar 2014 10:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRxLWZULLS7T; Thu, 13 Mar 2014 10:57:33 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D951039E8016; Thu, 13 Mar 2014 10:57:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: <5321E00C.2010107@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:170324 Archived-At: On 03/13/2014 09:42 AM, Dmitry Antipov wrote: > What about an attempt to avoid such a mess by examining current C > stack depth and check it against system limits, like suggested in the > patch below? Don't most systems solve the problem with guard pages these days? If so, Emacs should just rely on these pages, as that shouldn't require slowing down Ffuncall etc. And if not, if memory management is available Emacs could install a guard page of its own, again without slowing down the main interpreter loop. Also, the code as given won't work on systems that have split stacks (e.g., gcc -fsplit-stack), and would need to be ported to them. How about the following idea instead? Assume that there are guard pages, and have Emacs trap the resulting signal and do the right thing.