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 21:01:39 +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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101931"; 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 23:03:32 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 1jemA7-000QOu-OO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 23:03:31 +0200 Original-Received: from localhost ([::1]:39650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jemA6-0007yh-Ph for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 May 2020 17:03:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49224) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jem9e-0007xp-Ru for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 17:03:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jem9e-00069N-I8 for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 17:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jem9e-0007Ah-EB for bug-gnu-emacs@gnu.org; Fri, 29 May 2020 17:03: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 21:03: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.159078615827535 (code B ref 41321); Fri, 29 May 2020 21:03:02 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 29 May 2020 21:02:38 +0000 Original-Received: from localhost ([127.0.0.1]:56346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jem91-00079o-3g for submit@debbugs.gnu.org; Fri, 29 May 2020 17:02:38 -0400 Original-Received: from mail-ot1-f65.google.com ([209.85.210.65]:43687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jem8z-00079c-E9 for 41321@debbugs.gnu.org; Fri, 29 May 2020 17:02:21 -0400 Original-Received: by mail-ot1-f65.google.com with SMTP id u23so3009337otq.10 for <41321@debbugs.gnu.org>; Fri, 29 May 2020 14:02:21 -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:content-transfer-encoding; bh=IFgmzDXjUfNXDDlpl7+TzZFefc0yRHlMWH3djKbPD8Q=; b=tbCdpg6WIdka9tcOV1hJjIfCZ3NjkfNfZVGwt2Rd0a4Z9f+Mms8lc82K7hdo5drWW1 DkD3xSyA3O7sbBq4l1ZLGZgrAVbJ9sTgO+ZTw4U7CbUW+jJ2ntSD1oCAMqXF69OOpH53 DKQhGMro8OpUUhyMqNQ4rT0L2pw3Ft/nbx+HzsdfyUYqcheaFilhcSvSlRcaCwr64vis NSGVDad737HN9j0tNAsFB2W7HcUnHVVnwAOtqX2BdT/VvMW+N0nDUjpLNuwOBFnWwZa3 kM56tYqRiuVeCLNPIc0fJINVlLYjFIwaMuckDQvZG26bUufOvURi/s5qtMTqXNror/XN T3AQ== 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:content-transfer-encoding; bh=IFgmzDXjUfNXDDlpl7+TzZFefc0yRHlMWH3djKbPD8Q=; b=NHwwY903TUXDmFwPqWD4/NmW9uoVnmmyTmzyvtr8f85y3f9K5qMKx3c6daODytu0Hy XjrZLQ/kceb52+zUB5GI+ALOOyxjqL1NxyfDRwxedG3Rf4yGQUyJ47TxvSnRIzmSlwgh m8QQH/D7We+SOBnKObRqvWdkLLny5umLZrgqR0E/UGqID3whtJziqB+JOd9KY72sYJ69 t6xmqajYKNYlVa5KWHBFctsTa8CzR4nhlj6bU4MaCdRpMBwsG8LoFEGn/qnrM4HYAEhX nlN/ae2/rkcJJtwC+cCaN6uvh9hzoR7X2mIFXd6st6M7PHgia735kY0ZmSY8t4ZB7Dgm wFSw== X-Gm-Message-State: AOAM532RTFG9y/M+E/U/8WfrpH9ODL/fbkwzTN9bMuFVhZSFdF3tg86J 6p8x3uw9JPj3goSTkrCSyEfF2C1n98YSd2uin5U= X-Google-Smtp-Source: ABdhPJxsbH5U2jowYUP5sTDafTV/SwVZ5lTEmTuFNYsIZXwT1mx+5U16ArlhcqfFgTH5W1XumfL7ovOVx7f8gmT6lJs= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr7853955otn.287.1590786135685; Fri, 29 May 2020 14:02:15 -0700 (PDT) In-Reply-To: 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:181211 Archived-At: On Fri, May 29, 2020 at 8:24 PM Paul Eggert wrote: > On 5/28/20 11:19 PM, Eli Zaretskii wrote: > >> - return (uintptr_t) p % LISP_ALIGNMENT =3D=3D 0; > >> + return (uintptr_t) p % GCALIGNMENT =3D=3D 0; > >> } > > ...replacing LISP_ALIGNMENT with GCALIGNMENT just here doesn't sound > > right to me: by keeping the current value of LISP_ALIGNMENT, we > > basically declare that Lisp objects shall be aligned on that boundary, > > whereas that isn't really the case. Why not change the value of > > LISP_ALIGNMENT instead? > > There are really two bugs here. > > 1. The idea of taking the address modulo LISP_ALIGNMENT is wrong, as a po= inter > can point into the middle of (say) a pseudovector and not be > LISP_ALIGNMENT-aligned. Replacing LISP_ALIGNMENT with GCALIGNMENT does no= t fix > this bug in general, because such a pointer might not be GCALIGNMENT-alig= ned > either. This bug can cause crashes because it causes GC to think an objec= t is > garbage when it's not garbage. > > 2. LISP_ALIGNMENT is too large on MinGW and some other platforms. > > The patch I sent earlier attempted to be the simplest patch that would fi= x the > bug you observed on MinGW, which is a special case of (1). I'm not convinced. I think Eli only observed (2). There were no pointers into the middle of pseudovectors in his backtrace or disassembly... > It does not attempt > to fix all plausible cases of (1), nor does it address (2). It does address (2). It doesn't address all cases of (1). > We can fix these two bugs separately, by installing the attached patches = into > We can fix these two bugs separately, by installing the attached patches = into > emacs-27. The first patch fixes (1) and thus fixes the crash along with o= ther > plausible crashes. The second one fixes (2), and this fixes the MinGW cra= sh in a > different way but does not fix the crash on other plausible platforms. (1= ) > probably has better performance than (2), though I doubt whether users wi= ll notice. (1) says: It=E2=80=99s an invalid optimization, since pointers can address the middle of Lisp_Object data. That may be true (we still haven't observed it), but it's not what happened in Eli's case: in that case, the "pointer" was actually the lower half of a Lisp_Object, so it pointed at the beginning of a struct Lisp_Vector. That just happened to be misaligned. (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 !=3D 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.