[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: |
Paul Eggert |
Subject: |
bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects |
Date: |
Sat, 30 May 2020 09:31:49 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 5/29/20 2:01 PM, Pip Cet wrote:
> (1) says:
> It’s an invalid optimization, since pointers can address the
> middle of Lisp_Object data.
>
> That may be true (we still haven't observed it),
I observed it earlier, in code that iterated through a Lisp vector; at the
machine level the only pointer was into the middle of that vector. Addresses of
Lisp_Vector elements are not GCALIGNED on x86 and other platforms.
> but it's not what
> happened in Eli's case:
Yes, that's right. That is, the patch for (1) fixed not only Eli's case, but
other plausible cases.
> 1. malloc() % GCALIGNMENT != 0. Never happens, as far as I can tell.
Although that's true of all current Emacs porting targets as far as I know, I'd
rather not hardwire this into the code, as neither POSIX nor the C standard
require it. This is why the comment refers to platforms where malloc() % 8 != 0
as "oddball hosts".
> 2. A Lisp object requires greater alignment than malloc() gives it.
> IIRC, there was at least one RISC architecture whose specification
We don't need anything that obscure. Just use __int128 on x86 with glibc 2.24.
On that platform __int128's alignment is 16, malloc's is 8.
> I'm not saying it's the best solution, but I would prefer simply
> defining LISP_ALIGNMENT to be 8 to either patch.
That's not correct for !USE_LSB_TAG, where LISP_ALIGNMENT is merely the native
alignment (there's no need to align objects to 8 because the tags are at the
high end).
- 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/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
- 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
- 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
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects,
Paul Eggert <=
- 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, 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, 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, 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, Eli Zaretskii, 2020/05/31
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30