[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects
From: |
Eli Zaretskii |
Subject: |
bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects |
Date: |
Sat, 30 May 2020 08:58:05 +0300 |
> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 29 May 2020 21:01:39 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 41321@debbugs.gnu.org,
> Stefan Monnier <monnier@iro.umontreal.ca>
>
> (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.
Btw, can someone remind me why we started requiring non-default
alignment from Lisp objects?
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?
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, (continued)
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/27
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/27
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects,
Eli Zaretskii <=
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30