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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 30 May 2020 11:06:52 +0000
> Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, 
>       Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > I understand that part, but my question was why, even before the
> > change in max_align_t, did we start requiring 8-byte alignment on
> > systems where that is not automatically guaranteed?
> 
> I don't know. As I said, I think that was always buggy on pdumper
> systems, though the bug was very subtle. My guess is it predates
> pdumper, at which time it was a valid optimization.

How is pdumper involved here?

> > So this alignment requirement is only due to pthreads being used?
> 
> I'm not sure what you're asking. Obviously there are systems on which
> unaligned accesses will fault or be very slow indeed, so we need to
> make sure, say, pure space allocations are aligned somehow. That
> requires a LISP_ALIGNMENT of 8. Everything beyond that is only for
> performance, pthreads, and SIMD types.

If the system guarantees 4-byte alignment from malloc (and/or a
similar alignment of the runtime C stack), then using that doesn't
trigger problems related to unaligned accesses, right?  So let me
rephrase: why isn't 4-byte alignment "good enough" for us on systems
where malloc and the runtime stack are guaranteed to be thus aligned?

> > If
> > the two 32-bit parts of the object are non-contiguous, will we be able
> > to recognize such an object, and will we be able to mark it correctly,
> > and if so, how?  IOW, don't we need the upper 32-bit (which encodes
> > the object type) for the purposes of marking it?
> 
> For everything but symbols, we don't, mark_maybe_pointer called on the
> low 32 bits suffices. For symbols, mark_maybe_pointer needs to be
> changed to also check the pointer at <low 32-bit word> + &lispsym.

Right, that's what I thought.  So this issue also has to be fixed on
emacs-27 in order for us to provide a stable Emacs 27.