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: Wed, 23 Dec 2015 09:09:42 -0800 Organization: UCLA Computer Science Department Message-ID: <567AD556.6020202@cs.ucla.edu> 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> <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> 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 1450890614 22194 80.91.229.3 (23 Dec 2015 17:10:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 17:10:14 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, dancol@dancol.org, emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 23 18:10:04 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 1aBmvK-0007wA-FM for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 18:10:02 +0100 Original-Received: from localhost ([::1]:57068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmvJ-0004Pr-QQ for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 12:10:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmvF-0004PT-Az for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:09:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBmvD-0006bt-Jv for emacs-devel@gnu.org; Wed, 23 Dec 2015 12:09:56 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmv6-0006Z3-2Q; Wed, 23 Dec 2015 12:09:48 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 94F4016057C; Wed, 23 Dec 2015 09:09:46 -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 L8-rreuaZU30; Wed, 23 Dec 2015 09:09:45 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AD0EE160D24; Wed, 23 Dec 2015 09:09:45 -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 t4xhYj_Id6lv; Wed, 23 Dec 2015 09:09:45 -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 7B82916057C; Wed, 23 Dec 2015 09:09:45 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: 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:196720 Archived-At: Philipp Stephani wrote: >>> We could merely require that any module needing recursion must call a >> new stack-size-checking function at each level of recursion, in order to >> detect stack overflow. >> >> That's performance penalty. I don't think we should incur that, on >> behalf of a problem that really should "never" happen. >> > > It's also impossible. Modules will be written in arbitrary languages and > make use of arbitrary libraries, some of which might not even know about > Emacs's existence. We cannot impose any constraints on module code. There's also the issue that other languages may have their own assumptions about how stack overflow is detected, assumptions that may disagree with Emacs's method or even prevent Emacs's method with working. My own preference also is to rely on the usual VM techniques for ordinary C-code modules, and hope that other languages don't get in the way. Still, it may not be possible to do that, and we may be forced to impose a bit of software overflow-checking on modules implemented via recursion, for module authors who care about reliability. Does anybody know how C++ and/or Java and/or Python modules detect and recover from stack overflow on GNU/Linux? That would be a reasonable sanity check here. (And if nobody knows, that's not a good sign....) >>> Also, any module with an unbounded amount of computation should call the >> equivalent of QUIT every now and then. If the module API doesn't let (or >> ideally, require) modules to do that now, it should. Otherwise it's an >> Emacs freeze waiting to happen. >> >> I agree, but I think it's unrelated to stack overflow. (Though I >> think we will need to have a module-specific version of QUIT, as long >> as we keep the constraint of not directly longjmping from module >> code.) >> > > There's no harm in providing such a functionality (but of course we can't > enforce its use). We *could* enforce the use by requiring at least one call to QUIT every (say) 100 ms, and by doing the equivalent of 3x C-g when the time limit is exceeded. That'd be useful even without modules. > Even if we > assume "benign UB" (which is dangerous because UB tends to become more > malign as compilers evolve), it will cause internal state to become > inconsistent, which is truly disastrous. Emacs has been relying on this sort of "benign UB" for years, in areas just as disaster-prone as C++ cleanup, and it has worked well enough. I don't see why C++ would be any different. Typically C++ cleanup is just recovering memory, so we'll have a memory leak; big deal. > handle_sigsegv already has several cases where the longjmp is skipped: when > in a GC, when the signal is received from the wrong thread, and when it's > not guaranteed to be a SO. In those cases Emacs aborts (still autosaving). 1. You're right about the GC, but that aspect of GC is considered to be a bug (it's called "hard GC error" in the handle_sigsegv comment) and should not be precedent for us installing similar bugs elsewhere. 2. The wrong-thread check is because we are attempting to detect stack overflow only within Emacs (which can occur due to a user program error, which should not crash Emacs); stack-overflow errors in other threads are considered to be internal errors in Emacs and indeed never should happen, so it's OK to treat them as fatal errors (I expect this should be true even if the other threads were created by a module). > Why can't we do the same if SO is detected while a module function is > active? It might be reasonable to do that if the stack overflow were entirely due to the module -- that'd be like stack overflow in some other thread created by the module. But it would not work when Lisp code almost overflows the stack, then calls the module code, which overflows; in this case Emacs needs to recover rather than aborting.