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 07:19:18 +0000
> Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, 
>       Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > Btw, can someone remind me why we started requiring non-default
> > alignment from Lisp objects?
> 
> max_align_t was changed to include a float128 type, and
> alignof(float128) == 16 on x86, even though virtually all x86 systems
> are configured to allow unaligned accesses.

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?

> If I understand Paul's concerns correctly, he believes it's possible a
> system will once again come into use in which atomic accesses only
> work for offsets aligned to, say, 32 bytes. Since pthread variables
> require atomic accesses, such a platform would see weird crashes if a
> pthread inside a Lisp_Vector wasn't aligned to 32 bytes.

So this alignment requirement is only due to pthreads being used?  But
MinGW doesn't use pthreads.

> > 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?
> 
> Yes. The lower 32-bit part was ignored because its value wasn't
> 16-byte aligned, not because its stack location wasn't 8-byte aligned.

Right, but I'm talking about marking.  AFAIU, when scanning the stack
finds a value that looks like a Lisp object, we mark that object.  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?