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: Crash robustness (Was: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.) Date: Wed, 23 Dec 2015 19:30:23 +0200 Message-ID: <83a8p1oyxc.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> <83oadiqxq1.fsf@gnu.org> <5679B33E.9000804@dancol.org> <83y4cmp5y5.fsf@gnu.org> <5679B7F5.9030504@dancol.org> <83twnap4xa.fsf@gnu.org> <5679BE1D.5070903@dancol.org> <83poxxp2rl.fsf@gnu.org> <567ACB0F.9060804@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450891803 9937 80.91.229.3 (23 Dec 2015 17:30:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 17:30:03 +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 Wed Dec 23 18:30:02 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 1aBnEe-0006B7-4x for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 18:30:00 +0100 Original-Received: from localhost ([::1]:57188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnEd-00033w-Gx for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 12:29:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnEW-00033l-0t for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:29:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBnES-0004qo-R2 for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:29:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBnES-0004qf-N9; Wed, 23 Dec 2015 12:29:48 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2288 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBnER-00025r-Jm; Wed, 23 Dec 2015 12:29:48 -0500 In-reply-to: <567ACB0F.9060804@dancol.org> (message from Daniel Colascione on Wed, 23 Dec 2015 08:25:51 -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:196725 Archived-At: > Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com, > p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org > From: Daniel Colascione > Date: Wed, 23 Dec 2015 08:25:51 -0800 > > We can alloca, say, 8MB, and write to the start and end of the allocated > region. How do you know the alloca won't trigger stack overflow? > Then we'll know we have at least that much stack space available. At that point, yes. But you need to know that at many other points, when some of the stack is already used up. > > I simply don't see any trouble this could cause, except leaking some > > memory. Can you describe in enough detail a single use case where > > this could have any other adverse effects that we should care about > > when recovering from stack overflow? > > What happens if we overflow inside malloc? One possibility is that we'll > longjmp back to toplevel without releasing the heap lock, then deadlock > the next time we try to allocate. I very much doubt anything like that can happen. An malloc implementation which behaves like that won't last long. Lots of C programs longjmp from signal handlers, so interrupting malloc with, say, SIGINT, must work. I think even Emacs did something like that in the past, at least on a TTY, where C-g triggers SIGINT. > >> We have a program that has its own Lisp runtime, has its own memory > >> allocation system, uses its own virtual filesystem access layer, and > >> that brings itself back from the dead. We're well past replicating OS > >> functionality. > > > > Actually, most of the above is simply untrue: we use system allocators > > to allocate memory > > We have internal allocators for strings and conses and use the system > allocator only for backing storage. On some systems. Not on all of them. > , and if by "bringing itself from the dead" you allude to > > unexec, then what it does is a subset of what every linker does, > > hardly an OS stuff. > > Granted, that's toolchain work, not "OS" work, but it's still outside > the domain of most text editors. Sure. But a linker is still an application that reads and writes files. It doesn't futz with OS-level features like page protection and processor exceptions. > > Emacs is not safety-critical software. It doesn't need to be "safe" > > by your definition, if I understand it correctly. > > It's not safety-critical software, but undefined behavior is undefined. > What makes us confident that we can't corrupt buffer data by longjmping > from the wrong place? Nothing makes us confident. Recovery from stack overflow is not guaranteed to work in all cases. But if it works in some of them, it is already better than always crashing, IMO. > Anything can happen because we can longjmp from anywhere. Yes. But if we hit a stack overflow, we are already in deep trouble. > What if we just installed a SIGSEGV handler (or, on Windows, a vectored > exception handler) that wrote buffer contents to a special file on a > fatal signal, then allowed that fatal signal to propagate normally? I presume you mean auto-save, not save. We could try calling shut_down_emacs from the signal handler, but I'm not sure if the small alternate stack will be enough for write-region. Something to investigate, I guess. > The next time Emacs starts, we can restore the buffers we've saved > this way and ask users to save them --- just like autosave, but done > on-demand, at crash time, in C code, on the alternate signal stack. Why "like autosave"? What will be different from actually auto-saving? shut_down_emacs does that automatically.