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

[Pip Cet]

On Wed, May 27, 2020 at 4:58 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 5/27/20 8:26 AM, Eli Zaretskii wrote:
> > We used to rely on 8-byte alignment on those systems, and I don't see
> > any reason not to continue relying on that and punishing those
> > systems' performance.  What would we gain?
>
> In looking into this more, it appears that the maybe_lisp_pointer idea is 
> wrong,
> in that compilers can make pointers into a Lisp object while losing the 
> address
> of the original object (and we've seen them do this) and there's no guarantee
> that these sub-pointers are GCALIGNED.

Do you know of anything like this happening on 64-bit systems? Because
I think it doesn't; Emacs GC does rely, and has always relied since
GCPRO was removed, on compilers being sensible about what they put on
the stack. There's no guarantee in the C standard that that's true,
but there never will be.

> This sort of failure should be quite rare
> but can cause crashes such as the one you observed.

I'm pretty sure we figured out the crash that Eli observed. It's not
anything that involved, just a Lisp_Object being stored
non-consecutively and simultaneously being misaligned for the purposes
of maybe_lisp_pointer.

> I am looking into a fix and
> plan to apply it to master (I've already installed some minor glitches I
> observed on the way); we can then talk about what to do with emacs-27.

I may be out of line, but I think it's rash to change things like
that, even on master, with no opportunity for prior discussion. This
isn't a minor bug, or a spelling fix: it's a fundamental change in
what we expect from our C compiler and how GC works. In particular, I
don't see how you plan to solve it without treating any pointer that
points even in the vicinity of a valid lisp object as keeping that
object alive.