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: Sat, 30 May 2020 07:19:18 +0000 Message-ID: References: <83zha8cgpi.fsf@gnu.org> <83imgublku.fsf@gnu.org> <831rncjuwf.fsf@gnu.org> <83h7w5xvfa.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> <83tuzzrk30.fsf@gnu.org> <749bc7d0-6376-ec2e-7f84-dcd3a3cea465@cs.ucla.edu> <83sgfjqn49.fsf@gnu.org> <83eer2m0b6.fsf@gnu.org> 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="93763"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 30 09:21:10 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 1jevnp-000OGn-3R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 May 2020 09:21:09 +0200 Original-Received: from localhost ([::1]:43116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jevno-00059z-6U for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 May 2020 03:21:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jevni-00056h-AX for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 03:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45308) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jevni-0003bN-0m for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 03:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jevnh-0007H9-T6 for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 03:21: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: Sat, 30 May 2020 07:21: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.159082320427872 (code B ref 41321); Sat, 30 May 2020 07:21:01 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 30 May 2020 07:20:04 +0000 Original-Received: from localhost ([127.0.0.1]:56854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jevmm-0007FT-0X for submit@debbugs.gnu.org; Sat, 30 May 2020 03:20:04 -0400 Original-Received: from mail-oi1-f179.google.com ([209.85.167.179]:46111) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jevmj-0007Et-Ex for 41321@debbugs.gnu.org; Sat, 30 May 2020 03:20:02 -0400 Original-Received: by mail-oi1-f179.google.com with SMTP id b3so4680339oib.13 for <41321@debbugs.gnu.org>; Sat, 30 May 2020 00:20:01 -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=mkQpcZk6ZG6bMA9rW93/V0BtrHEKvMvFWwoILyvFSxY=; b=KOPLCrt8XjG76aP1ame1upLi+g6mYjeLJtZMQR6sxK0oU162gvDu+JQgG3+okVZUwu NABl/eKtzkJ/6JeeITuaqblTXLO7racY6BySJXMFdzEQxtQnK6tPGUGHQ0hu6PeDr3Rh wq5Kned83a/PhIAxg4pR1mzpH4y+gyTj6NAJCf6327Mk0EO75jW09iDvqttT/ui+bIZG B+/oj0rfPBgFUXGHyTZRQuX17fquBpOpM9/ldBEctUqamkfSZD+UiRWtC2vMol+H7xj2 KeTZZEspwr6SRDM9qByAcD+JUSNIzpMDR+ooYb9uxvFPXPITo/GYV5HKcxkxuZoJQmX1 cdBQ== 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=mkQpcZk6ZG6bMA9rW93/V0BtrHEKvMvFWwoILyvFSxY=; b=TGZ/PqbQgCLZfcQr/U364sB6A6PRcXMdsUk2pemzreBB08Fxm9ltIOaemq4czellXh qlHJvs68xM7bHyf7EGnM63KEH5jwMmWrnJIhv3wuvlyt8y8aCOCscaaREGZ+e4eJdcMa ZZgLgtAhAvVSxBGT3FfOVpVqUNTb3Dft1YYfKqLkSTKCHh+Zu/MvzrcXQVNqpl7ACX98 WvL1RxpWRbWTAquqIWrSQD/D4WobNlkLr2KcAMtQ2a+5OEXG0DWMnInr5zuIo9M2PFRt 846kTe10zVQRKctCoX2x0BfUlYhKsTSazxPckCL0ObgNoTCr4l3huE7mScUuI6wISfam zPkw== X-Gm-Message-State: AOAM532zNdKllfn5edr1c3Q+Tu6DYrY8S6ciRt7fHCHmwHFCYWyh5tl2 B36gqhjCWu3Wog0jG9+mbqSBI/o75oAc7f4uxcQ= X-Google-Smtp-Source: ABdhPJx492+++hqz+fLqYBsBX4e8Q54N/eaLJG8Asd+IhFvbh4Vkf8bxU+jIqRbN9M6fP9gKt+xWiq6wBv4DBp/CzH4= X-Received: by 2002:aca:b708:: with SMTP id h8mr8393981oif.122.1590823195830; Sat, 30 May 2020 00:19:55 -0700 (PDT) In-Reply-To: <83eer2m0b6.fsf@gnu.org> 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:181218 Archived-At: On Sat, May 30, 2020 at 5:58 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Fri, 29 May 2020 21:01:39 +0000 > > Cc: Eli Zaretskii , 41321@debbugs.gnu.org, > > Stefan Monnier > > > > (2) has this comment: > > +/* Alignment needed for memory blocks that are allocated via malloc > > + and that contain Lisp objects. On typical hosts malloc already > > + aligns sufficiently, but extra work is needed on oddball hosts > > + where Emacs would crash if malloc returned a non-GCALIGNED pointer. */ > > > > I can't make sense of that comment. It describes two problems that > > don't happen, and omits the problem that does happen. > > 1. malloc() % GCALIGNMENT != 0. Never happens, as far as I can tell. > > 2. A Lisp object requires greater alignment than malloc() gives it. > > IIRC, there was at least one RISC architecture whose specification > > supported atomic operations only on the first word in each > > 32-byte-aligned block, but that's such a rare case (and wasn't true > > for the silicon implementations, I seem to recall) that it seems silly > > to worry about it today. > > > > I'm not saying it's the best solution, but I would prefer simply > > defining LISP_ALIGNMENT to be 8 to either patch. > > I agree, but patch 2 basically does that, so I'm okay with saying "8" > in so many words. Okay. > Btw, can someone remind me why we started requiring non-default > alignment from Lisp objects? max_align_t was changed to include a float128 type, and alignof(float128) == 16 on x86, even though virtually all x86 systems are configured to allow unaligned accesses. If I understand Paul's concerns correctly, he believes it's possible a system will once again come into use in which atomic accesses only work for offsets aligned to, say, 32 bytes. Since pthread variables require atomic accesses, such a platform would see weird crashes if a pthread inside a Lisp_Vector wasn't aligned to 32 bytes. Of course, it remains to be seen/checked whether any such system would actually define max_align_t to have an alignment of 32, since it covers only primitive types. > Also, given the fact that in the crashing case the 2 32-bit parts of a > Lisp object were pushed onto the stack non-contiguously, will fixing > the alignment alone cause those Lisp objects to be marked? Yes. The lower 32-bit part was ignored because its value wasn't 16-byte aligned, not because its stack location wasn't 8-byte aligned.