From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Sat, 26 Nov 2016 01:04:18 -0800 Message-ID: References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <69a1fdf3-7120-125b-8556-d74f5afc6b37@dancol.org> <8360na399k.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1480151068 4918 195.159.176.226 (26 Nov 2016 09:04:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 09:04:28 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 10:04:24 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 1cAYuF-0000R4-0g for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 10:04:23 +0100 Original-Received: from localhost ([::1]:49714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAYuI-0003gp-Qo for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 04:04:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAYuD-0003gk-GD for emacs-devel@gnu.org; Sat, 26 Nov 2016 04:04:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAYuC-0005ay-NQ for emacs-devel@gnu.org; Sat, 26 Nov 2016 04:04:21 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50472) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cAYuC-0005aE-9h; Sat, 26 Nov 2016 04:04:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=Fs3ZhPLrnGotdixrF7CHS67xpM/13WW9f4v2g0XE/Sk=; b=coAxj7c+apf61eqo5rKnTz2af3I0oICzqoTo3ytzYBm/jcCzZm9x278BUZLemHT3kXayA664GEnsgpAIs70V2dWQ+Ic9FfGg1pxdxCroEB39Ck9HnlSWOvvpPbD7WtcRmvmg1gDp0OkcxB+vxsdTR5klBJTG8IYudPKcq5P80qDy6KZR8+gcIObtBcIOc32lLyOMDNrx4IgiaM9QYl//0MVmxWyU8hQ/h3VRd94Ghay/J6gd79KUfSEaUHiZQl2h8ChFKj6hXwGJFxmQD4vx4SNHqD22FWZaM2gNel7tOnVaFynR1CxiU15AfGaY7O/BekdYCyP+rxc8YiMPBgyVCA==; Original-Received: from [2601:602:9802:d9d1::350] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cAYuA-0002IN-Ou; Sat, 26 Nov 2016 01:04:18 -0800 In-Reply-To: <8360na399k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209609 Archived-At: On 11/26/2016 01:01 AM, Eli Zaretskii wrote: >> From: Daniel Colascione >> Date: Sat, 26 Nov 2016 00:33:13 -0800 >> >>>> 2) INTERVAL is GCed, but it's not represented in the memory tree: >>>> struct interval isn't a real lisp object and it's allocated as >>>> MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval >>>> won't protect it from GC. Shouldn't we treat intervals like conses? >>> >>> Does the code ever create an interval that is accessible only via locals >>> when a GC occurs? If not, Emacs should be OK. (This should also be >>> documented better.) >> >> Anywhere in the code? Forever? I wouldn't be confident saying so. > > A simple practical solution to such assumptions is to add an assertion > in some strategic place(s). > > I don't think it's TRT to sprinkle our sources with code that is there > "just in case", i.e. it will never actually run. How would you assert dynamically that if an interval is reachable, its owning string or buffer must be too? It's not enough for the variable holding the reference to the string or buffer to be in scope: you have to be sure that the reference isn't dead.