From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90 Date: Fri, 13 Mar 2020 11:39:54 +0200 Message-ID: <83o8t08ufp.fsf@gnu.org> References: <24162.58107.725366.668639@cochabamba.vanoostrum.org> <329e58b1-6255-311e-bdd8-b6f5b3d5208f@cs.ucla.edu> <22225b66-44f6-d132-3036-92181d53c28d@cs.ucla.edu> <89A83582-358F-43DC-B96E-04EE9D655D5F@vanoostrum.org> <63b88e2d-9888-f3ce-a4b0-fcf344e803e5@cs.ucla.edu> <83d09lbgk5.fsf@gnu.org> <837dzqaieq.fsf@gnu.org> <834kuuadod.fsf@gnu.org> <83blp1siku.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="5182"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39962@debbugs.gnu.org, pieter-l@vanoostrum.org, eggert@cs.ucla.edu To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 13 10:41:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jCgoa-0001ER-Jg for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 10:41:12 +0100 Original-Received: from localhost ([::1]:56152 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCgoZ-0003be-Mb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 05:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56431) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCgoS-0003ap-4H for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:41:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jCgoQ-0002nF-C4 for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:41:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52190) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jCgoQ-0002mw-8K for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jCgoQ-0003Ku-3t for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Mar 2020 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39962 X-GNU-PR-Package: emacs Original-Received: via spool by 39962-submit@debbugs.gnu.org id=B39962.158409241212742 (code B ref 39962); Fri, 13 Mar 2020 09:41:02 +0000 Original-Received: (at 39962) by debbugs.gnu.org; 13 Mar 2020 09:40:12 +0000 Original-Received: from localhost ([127.0.0.1]:58163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCgnb-0003JS-NQ for submit@debbugs.gnu.org; Fri, 13 Mar 2020 05:40:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCgnZ-0003J9-Bf for 39962@debbugs.gnu.org; Fri, 13 Mar 2020 05:40:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jCgnP-0007lA-KS; Fri, 13 Mar 2020 05:39:59 -0400 Original-Received: from [176.228.60.248] (port=1786 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jCgnP-0001oe-0R; Fri, 13 Mar 2020 05:39:59 -0400 In-Reply-To: (message from Pip Cet on Thu, 12 Mar 2020 20:36:10 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:177260 Archived-At: > From: Pip Cet > Date: Thu, 12 Mar 2020 20:36:10 +0000 > Cc: pieter-l@vanoostrum.org, 39962@debbugs.gnu.org, eggert@cs.ucla.edu > > > > It doesn't affect visible behavior of any callers, except in the case > > > where the previous behavior was buggy. > > > > I guess we have different notions of "visible" > > Please say something about your notion of "visible". It doesn't affect > any of the existing C callers of valid_lisp_object_p. Are you talking > about printing valid_lisp_object_p(x) in a debugger, and not getting > the expected value? Or something else? I'm talking about the behavior documented in the commentary. > > and "buggy". > > It avoids segfaults or random memory corruption. How is that not "buggy"? That's not the issue here. You said the proposed change didn't change the behavior "except where it was buggy"; I'm saying that it changes the behavior unrelated to this bug, where previous behavior was not buggy by any measure. > > > I'm most certainly not changing the semantics of live_buffer, if > > > that's what you're worried about. I am changing the semantics of > > > live_buffer_p, which is an internal function, and my initial patch > > > also changed the return value of valid_lisp_object_p, to another value > > > that would be treated equivalently. If there are objections to that, > > > we can easily distinguish the two cases. > > > > I actually don't understand why we need to make such a change. > > Which change? Treating the two cases differently? Because the garbage > collector needs to know whether an object is reachable, not whether > it's still a live buffer. So why does it not consider the buffer reachable in this case? The call to live_buffer_p is just one attempt to identify it as reachable; there are (or at least should be) others. > valid_lisp_object_p is currently documented to return 2 for a killed > buffer and 1 for a live buffer, which is weird since they're both > valid. It also returns 1 for some fake objects which aren't actually > valid: > > (gdb) p current_thread->m_current_buffer > $3 = (struct buffer *) 0x555556694b10 > (gdb) p valid_lisp_object_p(0x555556694b15) > $4 = 1 > (gdb) p valid_lisp_object_p(0x555556694b25) > $5 = 1 Why do you consider this incorrect? The Emacs GC is "conservative", which means it doesn't collect anything that _might_ be a valid Lisp object. In what ways does the above violate that contract? > If a buffer has been killed but is reachable only through > mark_maybe_object, we fail to mark it. > > We should mark it. In fact, whether a buffer object is marked should > depend only on whether it's reachable, not whether it's "live" in some > other sense. > > That's all my patch does. Your patch modifies the notion of whether a buffer is "live", on the assumption that this is the root cause of the failure to mark it. But do we have any evidence that this is the root cause? Because if not, your patch might just be a band-aid, and the real root cause will still be out there, even if we apply the patch. Moreover, by disregarding the indication of a killed buffer, doesn't your patch cause us not to GC killed buffers even though they are unreachable, or at least create a danger that we would? Buffers are objects that are created and killed a lot in any Emacs session, so failing to GC them would mean memory leaks. The way to understand what happened in your test case is to figure out how come the buffer was not found to be reachable via any other approach the GC makes. For example, shouldn't we have this buffer somewhere on the stack? if so, how come stack marking didn't find it? And if we don't have it on the stack, why not? > > > > The problem you are trying to solve is rare > > > > > > I think it would become much less rare with lexical binding in effect, > > > at least when the code's byte-compiled. > > > > That remains to be seen. > > How about we put out the fire rather than waiting to see whether it > causes any damage? The disagreement is whether there's fire, not whether we should put it out if there is. You've shown that you can start a fire if you want, but not that the fire is already out there, burning. E.g., I see no reason for some Lisp program to do what your test case does, it simply makes no sense. > And, if we can agree to do so, what would you like a patch which is > actually meant for inclusion into the emacs-27 branch (my previous > patch wasn't, obviously) to look like? If it isn't clear, I'm saying that your proposed patch is not necessarily TRT for master, either. I'd like to see more analysis of what exactly happens in that case, and why, along the above-mentioned lines, before I make up my mind. > > > > since this code was with us since 20 years ago without > > > > anyone bumping into it, > > > > > > That we know of. They might have just accrued it to random Emacs crashes. > > > > Then again, they might not. We don't really have any evidence to that > > effect, all we know is that the code survived virtually intact since > > the day it was written. > > I have no idea what you're trying to get at here. I'm saying that we have no evidence on which to base the arguments, so I suggest to drop this part of the dispute as counter-productive.