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 08:31:35 -0800 Organization: UCLA Computer Science Department Message-ID: <56894CE7.7090301@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> 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 1451838722 27290 80.91.229.3 (3 Jan 2016 16:32:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 16:32: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 17:31:52 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 1aFlZK-0008Io-7Y for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 17:31:46 +0100 Original-Received: from localhost ([::1]:42141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlZJ-0004m2-KQ for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 11:31:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlZF-0004lx-Dh for Emacs-devel@gnu.org; Sun, 03 Jan 2016 11:31:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFlZC-0007g5-87 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 11:31:41 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlZB-0007fn-VS; Sun, 03 Jan 2016 11:31:38 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2138F160D24; Sun, 3 Jan 2016 08:31:37 -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 c_8FRlvEIxXa; Sun, 3 Jan 2016 08:31:36 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 174F9160D97; Sun, 3 Jan 2016 08:31:36 -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 60e2BNiQy7ru; Sun, 3 Jan 2016 08:31:35 -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 E2D30160D24; Sun, 3 Jan 2016 08:31:35 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <56892FD6.8040708@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:197460 Archived-At: Daniel Colascione wrote: > In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to > detect C stack oerflow and longjmp back to toplevel. It's important to > note that we don't just longjmp when we're in a safe position: we > longjmp from *anywhere*, even if we're, say, in the middle of malloc. Although that particular code path may have been introduced recently, for decades Emacs has longjmped from arbitrary locations due to other signals, so adding a longjmp for SIGSEGV does not introduce new issues. > The code is fundamentally flawed and cannot be made to work > properly on any platform. The code is part of Emacs 24.5 and does not appear to be causing problems; at least, I don't recall any bug reports from the field. The other longjmps, which are fundamentally flawed in the same way, have been in Emacs for decades, and also seem to work well enough in practice. > No other program attempts to recover from > stack overflow this way. True, not *exactly* in this way, but Emacs is pretty special. > In practice, the Lisp stack depth limits provide enough protection That won't be true once once people link in dynamic modules, since the modules may not use Lisp and may exhaust the C stack. And even without modules, I recall people running into stack-overflow issues in the regular-expression code. Did that ever get fixed? Even if so, most likely other such issues are still lurking in the regexp code. > The existing auto-save logic > is good enough for data recovery, especially if we run the sigsegv > handler on the alternate signal stack (which we can make as large as we > want) when possible. Something like that could help, yes. But the existing auto-save logic can longjmp out, so I don't see how this would address your concern about longjmp. One possible way forward here is the approach recommended by GNU libsigsegv. See "About stack overflow handlers". In the past we've avoided libsigsegv's approach because it was considered to be too heavyweight, but it would be safer to do something along the lines that it suggests, or perhaps even to use libsigsegv if available. > If we keep this code in Emacs, it sets a precedent for other terrible > forms of crash recovery, like silently ignoring writes to NULL ... Naah. We're pragmatic, not stupid.