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 08:11:42 +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> <753eed58-287b-1c47-deef-0e343bca8e69@cs.ucla.edu> <1ce49934-ee4c-78b5-20ff-83f281aed4ee@cs.ucla.edu> <21d399ef-5d63-dcf5-d124-64d2820885ea@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="28813"; 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 Thu May 28 10:13: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 1jeDf4-0007IG-AN for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 10:13:10 +0200 Original-Received: from localhost ([::1]:53604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeDf3-0008VK-C4 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 04:13:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeDew-0008UU-WA for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 04:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39338) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeDew-0002SK-MM for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 04:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jeDew-00059u-FN for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 04:13: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 08:13: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.159065354619786 (code B ref 41321); Thu, 28 May 2020 08:13:02 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 28 May 2020 08:12:26 +0000 Original-Received: from localhost ([127.0.0.1]:50884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeDeM-000594-8H for submit@debbugs.gnu.org; Thu, 28 May 2020 04:12:26 -0400 Original-Received: from mail-oo1-f46.google.com ([209.85.161.46]:38413) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeDeL-00058r-2E for 41321@debbugs.gnu.org; Thu, 28 May 2020 04:12:25 -0400 Original-Received: by mail-oo1-f46.google.com with SMTP id i9so5567343ool.5 for <41321@debbugs.gnu.org>; Thu, 28 May 2020 01:12:25 -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=BzCRvpFPYO2nCPACi55I1UM1XJNVlzd0HxhAcrzfgME=; b=oPPDo90r1rq4nCE09wsSWUapUeX5Q1v0iLn1MN5CRveIjVvEM1+iorJzVKXAa4ditg E8BrEpKDdu7K52W3Zypd/47HRyLO+ceArQIbIeQT8R2V6DRmvggkHc9+hYz1RB4OGsTe DVGemXQGTeDJ/HisDCDHg3oFrHsSshq54GY++LEmMgEFcRE+SpChxmJc7a5ytqEiGiz9 XPbHIrwhoQSxEOr+r+JdvYV8FuW5fvfk5lVTqD6wMbvfE6ZTckxeQECINju0FPpPQkR/ UFIOHo570FXdoLXcQmZtH6rupXfFNgQUdm6zctWtzBMOMqqoZW9KTEal8Yemig0+J9ZL QlNw== 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=BzCRvpFPYO2nCPACi55I1UM1XJNVlzd0HxhAcrzfgME=; b=q+1hOpBuRceSPWgQBxW7J+eoeLk7UHhv/Di2jpMO01WusfQ1t2wcIVhZhY5FyqoAfo 233Kku+V72DhJE1wi+zg3J/nVMkPdiiQNulr34gAl28QmCTPDrymMco4ClIvH/m7Hpni 5KLMChUB5ZzbOqqdqxHm2cUUaxnhUfk8TiUCS12PjqqkK5Yv9ud9h04opo3pd7T3uXTg ue64cQJHbKLICYxSPPHoX7CWS+78cJQd+3S34nvF7l/0T9TW++um5DEJbKUEQIM1fjQ3 8zsBdgPiYJ+jH/aUCO2et6VqtJ5JrmoHn8pd++OVwGd5zh7CkERz6aMk/WotbfEBkco4 DgtA== X-Gm-Message-State: AOAM532a0pjw/Nkjs0Fo653bLzsNbyNy3NjsIlwCxMfh2W/mPZ6jVrkx kSJ7EbdqFKkhUUL+SiYj4gwN8UvnB4dxjA6uHTB4nS4+ X-Google-Smtp-Source: ABdhPJz8kq43llcOqE+7CDyB34O982SgAD/Co8Nb+WoZV9UxROB2f95lsZBdEmN/dMupTk0f6bhidIuVJRi6QVQI8t0= X-Received: by 2002:a4a:e702:: with SMTP id y2mr1613516oou.44.1590653539439; Thu, 28 May 2020 01:12:19 -0700 (PDT) In-Reply-To: <21d399ef-5d63-dcf5-d124-64d2820885ea@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:181132 Archived-At: On Thu, May 28, 2020 at 7:47 AM Paul Eggert wrote: > On 5/27/20 11:31 PM, Pip Cet wrote: > > I hope you're right, in that compilers will support GC better before > > they move on to clever optimizations that break it :-) > > After looking into it, I decided it wasn't worth the hassle of treating pointers > just past the end of a Lisp object as pointing into the object. Although such > pointers can exist, I can't think of a realistic-with-today's-compilers scenario > at the machine level where (1) a pointer like that will exist, (2) no pointers > into the middle or start of the object will exist, and (3) the object might be > accessed later. In contrast we have seen scenarios with pointers into the middle > of Lisp objects. Okay. I was about to write that I'd concluded the same thing, after failing to come up with an example other than that hypothetical Freverse implementation. > With that in mind, attached is a proposed patch to master that I hope deals with > some of the more-serious problems mentioned so far in this thread, in particular > the problem with Lisp_Object representations of symbols being split into two > registers in a --with-wide-int build. I haven't tested this as much as I'd like, > but I need to turn my attention to sleep and work and so this is a good place to > broadcast a checkpoint. Thanks! Looks great generally, though I confess I haven't checked what would happen in a (hypothetical?) !USE_LSB_TAG 64-bit case. + if (!symbol_only && live_float_p (m, p)) + obj = make_lisp_ptr (cp - (uintptr_t) cp % GCALIGNMENT, Lisp_Float); break; I'm not sure about this code, though, it assumes GCALIGNMENT == sizeof Lisp_Float. > PS. Thanks for helping bring this problem to our attention; it's been fun to > look into it. I agree. I'll certainly continue looking for bugs and working on Emacs, but at this point I'm unsure it's worth it to actually share such work with anyone. But that doesn't really belong here.