From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Sat, 26 Nov 2016 13:43:48 -0500 Message-ID: References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <83poli1di3.fsf@gnu.org> <83oa1219bo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480185880 16875 195.159.176.226 (26 Nov 2016 18:44:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 18:44:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 19:44:37 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cAhxk-0003gi-Ek for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 19:44:36 +0100 Original-Received: from localhost ([::1]:51462 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAhxo-0003b5-8k for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 13:44:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAhx9-0003ap-9m for emacs-devel@gnu.org; Sat, 26 Nov 2016 13:44:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAhx8-0006vp-GK for emacs-devel@gnu.org; Sat, 26 Nov 2016 13:43:59 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16420) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cAhx3-0006sK-O3; Sat, 26 Nov 2016 13:43:53 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CaBgALW9BX/9qixEVdHAEBBAEBgy0BAQEBAR6ETYVQsXmGFgQCAoFpPRABAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kiFUIvFUBAQEHAiWKfYQchgAFjx2KPJkNhguPDYE+NR+Ebh6DXIIuAQEB X-IPAS-Result: A0CaBgALW9BX/9qixEVdHAEBBAEBgy0BAQEBAR6ETYVQsXmGFgQCAoFpPRABAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kiFUIvFUBAQEHAiWKfYQchgAFjx2KPJkNhguPDYE+NR+Ebh6DXIIuAQEB X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="280710371" Original-Received: from 69-196-162-218.dsl.teksavvy.com (HELO milanesa.home) ([69.196.162.218]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Nov 2016 13:43:49 -0500 Original-Received: by milanesa.home (Postfix, from userid 20848) id 8CDBB660E7; Sat, 26 Nov 2016 13:43:48 -0500 (EST) In-Reply-To: <83oa1219bo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Nov 2016 18:42:51 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209623 Archived-At: >> Yes, basically, that kind of manipulation. > All of these cases are in intervals.c. > There are no other calls to make_interval anywhere in our sources. > So the question is: are those _the_only_ cases that you are talking > about, or do you see any others? I think the only code that manipulates struct intervals is in intervals.c, indeed, and the risks should be limited to this file. >> IOW it sounds difficult to make such a test be "complete" (catch >> most/all cases). > That doesn't mean we shouldn't do what we can. > Provided that we consider this danger to be real, of course. Right, it's a tradeoff. I personally don't think the tradeoffs favor writing such code (which is why I haven't done any such thing), as opposed to relying on code review (this code doesn't change very often). >> I also think it could prove fiddly to avoid false positives. > How can this cause false positives? I was mostly thinking of cases where the flag that signals we're in the process of manipulating intervals could stay set after the fact (because of non-local exit), but I'm sure there could be other cases (it will all depend on exactly what we check and how): false positives are pretty hard to avoid completely. > The current code doesn't allow any GC in those functions I described > above. This is purely a defensive technique against possible changes > in the future which will mistakenly allow that. Another approach would be to change the conservative GC code so as to also look for "struct intervals" pointers. We could do it "all the time", so as to just completely avoid the problem, or we could do it only depending on a debug flag and then signal an error when this extra code detects a reference that's not "redundant". In any case, so far I think it's just a problem in theory, but in practice I haven't seen any indication that we really have a problem. Stefan