bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects

[Paul Eggert <eggert@cs.ucla.edu>]

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).