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 18:37:42 +0000 Message-ID: References: <83zha8cgpi.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> <00884bff-c7ca-9f67-c3ec-cd3963ca1cb9@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="118654"; 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 20:39:16 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 1jejuW-000Ukd-Ic for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 20:39:16 +0200 Original-Received: from localhost ([::1]:45308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jejuV-0000F1-Gs for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 14:39:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jejuI-0000Eg-5C for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 14:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jejuH-0000vk-RU for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 14:39:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jejuH-0003ME-Pb for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 14:39:01 -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 18:39:01 +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.159077751412872 (code B ref 41321); Fri, 29 May 2020 18:39:01 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 29 May 2020 18:38:34 +0000 Original-Received: from localhost ([127.0.0.1]:56228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jejtp-0003LY-PT for submit@debbugs.gnu.org; Fri, 29 May 2020 14:38:33 -0400 Original-Received: from mail-oi1-f196.google.com ([209.85.167.196]:34021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jejtn-0003LL-Ob for 41321@debbugs.gnu.org; Fri, 29 May 2020 14:38:32 -0400 Original-Received: by mail-oi1-f196.google.com with SMTP id w4so3501060oia.1 for <41321@debbugs.gnu.org>; Fri, 29 May 2020 11:38:31 -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=SmqTcGCaio0W9RxMpoDh9RPN/TJ9XjATxqOPnNrsI0g=; b=C0dns8NkDRrTzIvgEcJoR1l0z20PCT5ylsDqAnLVwViafdhr/+3ERH60XrE0o7wWSl 94z7H3Phqs0a22N/bEJABZRVxifYFc2RCm7/Ri5ZF/15CRpYKqMc+6kVb5fBsleAxNLW jVZj7RYu6bZdAEEN7JY5hzo59WismmFx2BB7oAGrSth9fvs0GRn3uMUKYYQTSP4+fuKR vzD0UGbXBh0uC9VRSx+qxG50x35cQBNMxcKwfTSubZbm7Pd98nrdJ2HCwRag8H3R1Sxu yjDVsx1AsH+wNgiwu2gzpZ1PQ7FWI1egt5MrVyO4cMlzLc4IryvdF7yAHqTWctEAfUTb BJKw== 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=SmqTcGCaio0W9RxMpoDh9RPN/TJ9XjATxqOPnNrsI0g=; b=d5JPwvr8ZKj56q0NZYFkSBRXi319YpXBSZdomP7ozqFzyusGPOKChEby6AW8XZ6oMg SpbXwSHECV9RAtqKq8WwDBQNViHnpoldIWDwZeQ73JdbWkPNqAzB5soizcBgf/+znj0A SX92AjRSygCSgbwOupqF7IbRmTnXwalhACzJF14E9HfxdQJWY8FW8UC3ZjgPYaMIqLn/ iu0Rbd2/GvP+d5Z9XNyUfT22BoEr32uuYDGxlumnrUMsDOfvsOAYrOUT3BVGAKA/W+kf hifWbpY0z8dLUbDUm5Jau5942BWdGDL5LZGq2XZxX/fVXtsAP6eltehXYiKVVrGm99BG QvsQ== X-Gm-Message-State: AOAM530pyDaAo+iao1Y9fZSJzkfAYduB1glDAv20Orc1x+yIT7+rRiLB LG/Ne0CjN+HHS5Q/lQ563nUMYjkSMkRnUTonAtk= X-Google-Smtp-Source: ABdhPJxLLIOe8PikxeS9eX46GOAkJ7EI1Sx9wCqNx1Oq7H0HkhEx0ku21MhMN+6w1ZMOmPubaAxzZM30LVBsOtB4f1E= X-Received: by 2002:aca:c6d3:: with SMTP id w202mr7391912oif.44.1590777500572; Fri, 29 May 2020 11:38:20 -0700 (PDT) In-Reply-To: <00884bff-c7ca-9f67-c3ec-cd3963ca1cb9@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:181200 Archived-At: On Fri, May 29, 2020 at 6:31 PM Paul Eggert wrote: > On 5/29/20 2:43 AM, Pip Cet wrote: > > As I said, the code is tricky (i.e. might contain bugs that can only > > be discovered through extensive testing on 32-bit systems), and it > > complicates what should be generic functions for the rbtree > > implementation, so this is probably a 32-bit optimization that is too > > late because 32-bit systems are no longer that relevant... > > At least at first, it may make more sense to keep the red-black trees as-is, and > to look up what appear to be symbol-tagged pointers twice, once as-is (to find > any kind of object) and once offset by '(char *) lispsym - Lisp_Symbol' (to find > only symbols). Having had some time to think about this, I agree. I'm certainly not very confident in that code. But the main reason is that it's not an optimization in all circumstances: 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. 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. Of course, on 64-bit machines, this line of code would usually save us the trouble: if (start < min_heap_address || start > max_heap_address) return MEM_NIL; So that's another reason to leave the code as it is for now. > Although a bit slower, this won't require any changes to the > rbtree code so it's cleaner. > We can then time the optimization you have in mind, to see whether it's worth doing. ... or something simpler that might actually work better :-)