From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90 Date: Thu, 12 Mar 2020 20:36:10 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="126076"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39962@debbugs.gnu.org, pieter-l@vanoostrum.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 12 21:37:15 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 1jCUZt-000Wfi-Kz for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Mar 2020 21:37:13 +0100 Original-Received: from localhost ([::1]:50296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCUZs-00033B-Fq for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Mar 2020 16:37:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56733) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCUZj-000334-QY for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2020 16:37:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jCUZi-0002zU-In for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2020 16:37:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51878) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jCUZi-0002zE-Ed for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2020 16:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jCUZi-0001oT-BB for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2020 16:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Mar 2020 20:37: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.15840454146946 (code B ref 39962); Thu, 12 Mar 2020 20:37:02 +0000 Original-Received: (at 39962) by debbugs.gnu.org; 12 Mar 2020 20:36:54 +0000 Original-Received: from localhost ([127.0.0.1]:57851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCUZa-0001nx-A4 for submit@debbugs.gnu.org; Thu, 12 Mar 2020 16:36:54 -0400 Original-Received: from mail-oi1-f180.google.com ([209.85.167.180]:44781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCUZZ-0001nk-95 for 39962@debbugs.gnu.org; Thu, 12 Mar 2020 16:36:53 -0400 Original-Received: by mail-oi1-f180.google.com with SMTP id d62so6927985oia.11 for <39962@debbugs.gnu.org>; Thu, 12 Mar 2020 13:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fV1rLq1VJQ0xEdx0AAGcTHAhxMSfVGjh6gNbUIHKqhw=; b=Kf4xOinzZ12w0SYJ4gjGzknr5sfVUFou5azKbhkerbgOv/3L6V/QScXOvdwxylG699 WxxIUqtyNl87XXuwQZ4cQgB3U2shqdgAWF8FP5Ue1i65LT5poOM5v3RLR27SpR35jost pOIItqDbMYI7O74kLf0CoLG73EeTWXoSUBfzhX8xBEq6dvMSNch+lwjCf4K10Sqr/6vd nWdr97vR2EnBZy3Q/5DXG8GxVBeWjV8hFrRtuQQURorxMiTYYPWlf10c6an8wnBFF7ma 5bCg4VmSsfqELo52EwMnfl8dGBk+iNTueE11LEir251zQICw3eZDcdp/MRMcgQSJ8xCO eCig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fV1rLq1VJQ0xEdx0AAGcTHAhxMSfVGjh6gNbUIHKqhw=; b=od3R8xt2UAy1YtPdIUMlAm2oQGkDPxfxIwkfzCStObCwLbCciC5akeO0vYvitZoUkL UVyorVJ9EdPtvU6yZh9AUeFaK/arcE+j/frwH1NCo2WSYWwiS83ePlJneMdj+ENUTpEn 2929EI1dE4czL35KsvUA9Np1KQGg/wQ1lhJ6lS1QMMjQ6pU8ycwziNKVTccahfCq4Y+1 7nb/NPggvRdYZH9zg2PEz0UD4dWecQ40m6bAthXfts0ykUbcZuRjggTEb2Pd2ciwbVUi +nZtZBnF8hCEcpesrr+OdRhi/9rNFdyCQ4DRA6EYfKIUBxFablKHC9XHUtIwYBmBWPO8 m+Mg== X-Gm-Message-State: ANhLgQ3NVbMxHs9OvDBfEu2jEjAYxddwukyD3+sEimgWGDCkv3oe+GOs nTufTEb8NWPv55emRcXzFnLlclpo9h+seoAMFE4= X-Google-Smtp-Source: ADFU+vuaXjSJEReWpoUkO/WdN85tsXGGrDXiCNtjITw4872XIMll3jnKXmVQAcFWIorTF9QbPKPu2LED4xmncEUkAtk= X-Received: by 2002:aca:b9c2:: with SMTP id j185mr4035721oif.112.1584045407649; Thu, 12 Mar 2020 13:36:47 -0700 (PDT) In-Reply-To: <83blp1siku.fsf@gnu.org> 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:177233 Archived-At: On Thu, Mar 12, 2020 at 3:23 PM Eli Zaretskii wrote: > > > > > Did you audit all the users of this function, both direct and > > > > > indirect? Some of them are outside of GC. > > > > > > > > Thanks for the comment; I just re-checked, and they look fine to me. > > > > > > ??? Fine in what way? > > > > 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? > and "buggy". It avoids segfaults or random memory corruption. How is that not "buggy"? > > 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. 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 Luckily, no one relies upon that documented mis-feature, so it's safe to remove it. > > And I think "so we don't collect reachable objects" is a fairly good > > reason, generally. > > I didn't say it wasn't good, I said it didn't justify the proposed > solution. > How about if you tell more about the root cause of the crash you are > trying to solve, and why disregarding the fact that a buffer is killed > is the way to solve it? I can try. The garbage collector needs to mark all reachable objects. It can get away with marking unreachable objects (and does so, for overlays in killed buffers), but not marking a reachable object is a serious bug. If a buffer is live, everything is fine. If a buffer has been killed but is unreachable, everything is fine; it will be collected by GC. If a buffer has been killed but is reachable through mark_object, everything is fine. 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. > > > 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? 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? > > > 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.