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#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects Date: Thu, 28 May 2020 14:28:29 +0000 Message-ID: References: <83zha8cgpi.fsf@gnu.org> <83y2phwb9x.fsf@gnu.org> <83r1v9w9vi.fsf@gnu.org> <83mu5xw50d.fsf@gnu.org> <83k110wxte.fsf@gnu.org> <4bab5f55-95fe-cf34-e490-1d4319728395@cs.ucla.edu> <837dwyvi74.fsf@gnu.org> <1484f569-c260-9fb0-bfe1-67897de289d3@cs.ucla.edu> <83blm9tn4j.fsf@gnu.org> <4aeb8963-4fd1-fcd4-e6e1-be409ab54775@cs.ucla.edu> <83r1v5s2p1.fsf@gnu.org> <5351703b-1780-561b-7f68-cdd4ed45e599@cs.ucla.edu> <838shcseng.fsf@gnu.org> <309544a0-d857-13f3-e211-41a40966dcc5@cs.ucla.edu> 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="126590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , 41321@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 28 16:30: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 1jeJXv-000WmB-Um for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 16:30:12 +0200 Original-Received: from localhost ([::1]:59630 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeJXu-0003br-Gb for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 10:30:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeJXm-0003bc-Qp for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 10:30:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeJXm-0007U3-Hl for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 10:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jeJXm-0002XJ-Ct for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 10:30: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, 28 May 2020 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41321 X-GNU-PR-Package: emacs Original-Received: via spool by 41321-submit@debbugs.gnu.org id=B41321.15906761539662 (code B ref 41321); Thu, 28 May 2020 14:30:02 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 28 May 2020 14:29:13 +0000 Original-Received: from localhost ([127.0.0.1]:52721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeJWz-0002Vm-9j for submit@debbugs.gnu.org; Thu, 28 May 2020 10:29:13 -0400 Original-Received: from mail-oo1-f47.google.com ([209.85.161.47]:45521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeJWy-0002VZ-B2 for 41321@debbugs.gnu.org; Thu, 28 May 2020 10:29:12 -0400 Original-Received: by mail-oo1-f47.google.com with SMTP id p9so262603oot.12 for <41321@debbugs.gnu.org>; Thu, 28 May 2020 07:29:12 -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=ExvjXrAOpYNQPllgrs5X5MfU3PXBZWaOtkNkdq3GEoc=; b=ELEzI+ZtsmkN6uePMJblJ7e2PZ0Fmsx6P/0AlptqsdZvnXMR4+dcS5lYOfzHPHR42p 0pzX3gfBIRor/+kYSs7fNTJwN7Zrb6qF2xNKaoYumXaPEl/MXjQtODzrZVe863SRzyyc W0xzaIFdYQSSOB1Ibe7B/QydWdDs+NcTgteE+E697t9/6phCk10hI/186mD2ObmRTiY4 kA3JWa6CS0WPgA525PzwydTMXu1iaU+t8fTFQRunALET3NjOGqH4C9Ya0dZy+VJI1bfE hKTefjrYhT7+ZK1RPqiKmQlC8N58E4QEOng9DH+x8DSBNbyJZCQPi7kcR2m+yTkFklJs jFcA== 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=ExvjXrAOpYNQPllgrs5X5MfU3PXBZWaOtkNkdq3GEoc=; b=CoFJP4ljuE4KdRgLRRUpzshoKS+u+ILcfoorz7QEBtYurFtC1zl725xVpx2yF+XL8c 0bcrw5f+NvJrWtxP9E9dDWC/eYJUZA/H2EvWeU/P2I+eqcORkyNzQE/4vgDRkz41w2KH iyVaRBsEjtcuqhAJM1zUUifvBnKYYSFfkDpRQXYbBNkuoy9ndMUX/dXOzrKaAtscQHVt enrjON4iNToYdjPnHvPYLCTwNi1ErTQ1XCHMhXmIw3RhhSCpBlew83RMpQq7eXN4Oev9 xXUisjgoz6y2xsys2DtrxnopSGgXUfEdKlj+b2aLEet/a/EXq1jqKE7iT1iuLayHTt51 SeMw== X-Gm-Message-State: AOAM532QwKHX45hMqr8I4InVtPprK0k8EkkXLpvVylGfivAepQHhPHlz 0bElY7EOBba1kHp46kn0iP8f5TT6mTZqdbjnH1s= X-Google-Smtp-Source: ABdhPJw/pPfJQmMk+mp1X9qXOGtZu3mCGCktmr5m3R0tdFewiQZwIXxrysgyMKH2kGLTXj/+ClPDZUIvHRhTxEitktE= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr2709718oon.22.1590676146492; Thu, 28 May 2020 07:29:06 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:181140 Archived-At: On Thu, May 28, 2020 at 1:30 PM Stefan Monnier wrote: > >> You are suggesting that we go back to using live_string_p? > > I think he's saying just the opposite: namely, that maybe_lisp_pointer is a > > mistake, in that it goes against the (solid) reasons we've replaced some calls > > to live_string_p with calls to live_string_holding. > > After looking into it I agree. I'll propose a patch shortly that does away with > > maybe_lisp_pointer. > > Exactly. More specifically, `maybe_lisp_pointer` tries to filter out > false positives but does it based on the assumption that we should only > accept numbers that look like pointers to the beginning of > a Lisp_Object. > > If we still want to try and filter out false positives we need to do it > more carefully by considering what is the smallest alignment possible > for a pointer to an internal field of a Lisp_Object. > > And if this least alignment is not the same for all Lisp_Objects, then > this test should likely be moved to the respective `live__holding`. But at that point, we already have walked the rbtree, which is probably the main performance problem. My suggestion is instead to put MEM_TYPE_SYMBOL blocks into the rbtree twice, once at their proper address and once at the lispsym-based offset. We could then look up each pointer precisely once, though sometimes the blocks might overlap and we'd end up marking two objects for one pointer. But that would lead to overlapping rbtree entries, and that requires some extra code which wouldn't be exercised very often... still, I think it might be worth doing, particularly since there are relatively few symbol blocks on most systems. > I suspect that for vectorlike objects, the least alignement is 1 because > of some `char` or `bool` fields in some of the pseudovectors. > Of course, we could do better by checking for "false positives" after > checking the specific kind of vectorlike object (so as to use > a different least-alignment-check for those objects that contains > `char`s than for those who only contain `int`s, for example). I think the point of maybe_lisp_pointer wasn't to mark fewer objects, it was to look up fewer pointers in the rbtree. I might be wrong. On 64-bit systems with ASLR, at least, it's quite unlikely that we have what looks like a valid pointer into a Lisp object that we can conclude is not based on its offset or alignment...