From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects Date: Sat, 30 May 2020 15:18:53 -0700 Organization: UCLA Computer Science Department 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> <83tuzzrk30.fsf@gnu.org> <749bc7d0-6376-ec2e-7f84-dcd3a3cea465@cs.ucla.edu> <83sgfjqn49.fsf@gnu.org> <7c66e510-a8e6-17d0-94b1-793b49f87a37@cs.ucla.edu> <83tuzxl6gu.fsf@gnu.org> <782f3b14-ff24-fa26-5bd1-fa0db013bf8c@cs.ucla.edu> <83r1v1l4ls.fsf@gnu.org> <3399f152-27aa-3854-d741-e9dfaaa00fc7@cs.ucla.edu> <83mu5pl1wk.fsf@gnu.org> <5c746672-9f07-0314-500c-dc46e0c5b764@cs.ucla.edu> <83imgdkyk8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="113481"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: 41321@debbugs.gnu.org, monnier@iro.umontreal.ca, pipcet@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 31 00:20:11 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 1jf9pr-000TQC-0P for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 May 2020 00:20:11 +0200 Original-Received: from localhost ([::1]:45196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jf9pp-0003v3-O3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 May 2020 18:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44306) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jf9pi-0003uv-CE for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 18:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47811) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jf9pi-00075P-2S for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 18:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jf9ph-0004KC-Sw for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 18:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 May 2020 22:20: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.159087714516557 (code B ref 41321); Sat, 30 May 2020 22:20:01 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 30 May 2020 22:19:05 +0000 Original-Received: from localhost ([127.0.0.1]:59357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf9on-0004Iy-DK for submit@debbugs.gnu.org; Sat, 30 May 2020 18:19:05 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf9ol-0004IR-B8 for 41321@debbugs.gnu.org; Sat, 30 May 2020 18:19:03 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2F2D11600AF; Sat, 30 May 2020 15:18:57 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7AHgWE6OzUvw; Sat, 30 May 2020 15:18:55 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B49FE1600D9; Sat, 30 May 2020 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iM1Kpj5XGVy4; Sat, 30 May 2020 15:18:55 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 953E61600AF; Sat, 30 May 2020 15:18:55 -0700 (PDT) In-Reply-To: <83imgdkyk8.fsf@gnu.org> Content-Language: en-US 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:181265 Archived-At: On 5/30/20 12:33 PM, Eli Zaretskii wrote: > Posix may require it, but do we actually know of any supported > important platforms where this happens? That depends on what the question is. If the question is "Are there platforms where the lost-marker bug occurs?", then no, we don't know of any supported important platforms. But if the question is "Are there platforms where LISP_ALIGNMENT should be some value other than 8?", then yes, LISP_ALIGNMENT should be 4 on Ubuntu 18.04.3 i386 when Emacs is configured --with-wide-int (I just tested this, and it is indeed 4 on that platform in the Emacs master branch). This is because on this platform Lisp objects have a native alignment of 4, and this platform is !USE_LSB_TAG so the presence of tag bits imposes no extra alignment requirement. > let's worry about the > more general fix on master, where we still have time to try various > solutions, and settle for a simpler and easier fix on emacs-27. Yes, that's what we're trying to do, and it's what's in the latest patch that Pip Cet and I proposed very similar variants of. > But your proposal is also less efficient, isn't it? If so, its more > general nature comes at a price. Sure. Compared to simply making LISP_ALIGNMENT = 8 as a workaround (which is not correct as noted above but which fixes the lost-marker bug), the proposed patch is about a 1% CPU-time hit in my usual benchmark (make compile-always) on a 32-bit platform compiled with --with-wide-int (this is Ubuntu 18.04.4, gcc -m32, Xeon E3-1225 v2). We can surely speed this up with some cost in complexity (that's what I was working on on the master branch), but for emacs-27 I thought that reliability took precedence over 1% performance improvements. I expect that most of the performance hit is not due to the LISP_ALIGNMENT thing, it's due to the "you have to check pointers three times" thing. In my master-branch draft I'm working on getting this down to "you have to check pointers an average of 1+epsilon times" for some suitable value of epsilon. I don't know yet what epsilon will be. But anyway, this is only about improving that 1% performance hit.