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: Fri, 29 May 2020 19:37:29 +0000 Message-ID: References: <83zha8cgpi.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> <00884bff-c7ca-9f67-c3ec-cd3963ca1cb9@cs.ucla.edu> <6fa1ac99-c972-881e-180b-e49d0513504c@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="121314"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41321@debbugs.gnu.org, Stefan Monnier To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 29 21:39:14 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 1jekqU-000VNM-Gl for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 21:39:10 +0200 Original-Received: from localhost ([::1]:49450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jekqT-0007aA-Gc for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 15:39:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jekqM-0007a3-Py for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 15:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44721) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jekqM-0006yj-GW for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 15:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jekqM-00055t-DP for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 15:39: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: Fri, 29 May 2020 19:39: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.159078109819525 (code B ref 41321); Fri, 29 May 2020 19:39:02 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 29 May 2020 19:38:18 +0000 Original-Received: from localhost ([127.0.0.1]:56267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jekpZ-00054n-IP for submit@debbugs.gnu.org; Fri, 29 May 2020 15:38:18 -0400 Original-Received: from mail-ot1-f42.google.com ([209.85.210.42]:34992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jekpX-00054a-Sk for 41321@debbugs.gnu.org; Fri, 29 May 2020 15:38:12 -0400 Original-Received: by mail-ot1-f42.google.com with SMTP id 69so2865717otv.2 for <41321@debbugs.gnu.org>; Fri, 29 May 2020 12:38:11 -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=mCqQs4gBkBu7+8czQbBwbZCDFVQyWoWIkA1d+8SjXzA=; b=dP9eA/BQTzEZ1dGMvgMCj+YC3f/bfIlZOFTY4MSAGl/0Nb0dPVgDs+ZvgbLVCWBPoJ ahXHqtDUkVLnXqak5trY7mDL1Mwh28EmXHL29JnRT+5flul/kwqwN8p/hxBu4Gk5T7xT DVv5ImaLagIvijnq7GDu0eM4Xc0gOhy6bn1j6ffmDlxh5JuaEwzj7oeFStx6kvzFWx4u olyS7atzk9L8GSA/1DHeGEWxuIPxU92ZH9qZNUG2GANIZDGrBYAPPBtx37nlaMN3QRiF 9jHVUrLJHi6Z5uSujl/KSeU0/VqfYdoVdGdrAUdCAjV2UXbnpEtztovmnVZkXXWGlxF1 b6tQ== 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=mCqQs4gBkBu7+8czQbBwbZCDFVQyWoWIkA1d+8SjXzA=; b=Z67738thv16z5Rr0LKKwbbvk2MOnJN4TeX7mgl1Yfri07lLQVI1OzU6rMip0E09WO2 eR+Yz9AjThhjzgJMFFyj5RGntxPFXNLtsKVqVT3Zdwz7efEQOsjU4A8qKyTeP2LhyvdS OWPeZUD1vzH/G8KbGZoVDgJUwdJK74+uLhz7+TxwlQF3XtrOLwfq8N3B4DXPBxxrOX7J k9zlj3TlJ5Jew2MudFNK7YIKXJZyVmql2JEouDEmae6eOr5iLNAXF08KGMKMsboa8aXF 8f+RFPS4xYp9J6UzUeQB69BFPf/vjDJol0SazjuNmUYaPLZHmaSjsvYylmBeQIEbHgNO 0nng== X-Gm-Message-State: AOAM532FSmS7Te3TMQB5YF8tS5vWs4hJTf8y2+a3exFQV6Qi0QW/Mm3/ mBYU8neP4C92iwrEzTJwQwXkrRywY603WMNEQ/E= X-Google-Smtp-Source: ABdhPJw2ctcEZYIaS9wzFZ6XDJDHgtsOK39aBfkJjGXE4AckLbwSN+ttFlYgfEkNXAhTdoeB7JnwFjIiKIgsAI90iFg= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr7612103otn.287.1590781086078; Fri, 29 May 2020 12:38:06 -0700 (PDT) In-Reply-To: <6fa1ac99-c972-881e-180b-e49d0513504c@cs.ucla.edu> 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:181202 Archived-At: On Fri, May 29, 2020 at 7:32 PM Paul Eggert wrote: > On 5/29/20 11:37 AM, Pip Cet wrote: > > if you have a very large vector, and a symbol block > > aliasing it as symbol offsets goes away, you have to search for other > > symbol blocks with that property, which might take a long time. > > It shouldn't be that bad, because when you are worrying about symbols offset by > 'lispsym', you need to look only for symbol blocks; it won't matter if these > values appear to point into a vector because you won't follow them in that case. You mean it shouldn't be that bad with the existing code? You're probably right. It would have been very bad with the code I posted though, so best ignore that. > > However, I wonder what you mean by "what appear to be symbol-tagged > > pointers"? Surely we need to look up all pointers twice, no matter > > what their tag is, since they might be a reference to something inside > > the struct Lisp_Symbol. > > What I was trying to say is that if a pointer lacks the symbol tag, then we > needn't worry about it being offset by 'lispsym'. These pointers need to be > looked up only once, even if they happen to be pointers into a struct > Lisp_Symbol. We can safely assume that a compiler won't take a Lisp_Object that > is a symbol, and add a small offset to it without also adding 'lispsym'. Oh! You're right, of course. How silly of me not to realize.