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

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

On 5/30/20 12:33 PM, Eli Zaretskii wrote:

> Posix may require it, but do we actually know of any supported
> important platforms where this happens?

That depends on what the question is. If the question is "Are there 
platforms where the lost-marker bug occurs?", then no, we don't know of 
any supported important platforms. But if the question is "Are there 
platforms where LISP_ALIGNMENT should be some value other than 8?", then 
yes, LISP_ALIGNMENT should be 4 on Ubuntu 18.04.3 i386 when Emacs is 
configured --with-wide-int (I just tested this, and it is indeed 4 on 
that platform in the Emacs master branch). This is because on this 
platform Lisp objects have a native alignment of 4, and this platform is 
!USE_LSB_TAG so the presence of tag bits imposes no extra alignment 
requirement.

> let's worry about the
> more general fix on master, where we still have time to try various
> solutions, and settle for a simpler and easier fix on emacs-27.

Yes, that's what we're trying to do, and it's what's in the latest patch 
that Pip Cet and I proposed very similar variants of.

> But your proposal is also less efficient, isn't it?   If so, its more
> general nature comes at a price.

Sure. Compared to simply making LISP_ALIGNMENT = 8 as a workaround 
(which is not correct as noted above but which fixes the lost-marker 
bug), the proposed patch is about a 1% CPU-time hit in my usual 
benchmark (make compile-always) on a 32-bit platform compiled with 
--with-wide-int (this is Ubuntu 18.04.4, gcc -m32, Xeon E3-1225 v2). We 
can surely speed this up with some cost in complexity (that's what I was 
working on on the master branch), but for emacs-27 I thought that 
reliability took precedence over 1% performance improvements.

I expect that most of the performance hit is not due to the 
LISP_ALIGNMENT thing, it's due to the "you have to check pointers three 
times" thing. In my master-branch draft I'm working on getting this down 
to "you have to check pointers an average of 1+epsilon times" for some 
suitable value of epsilon. I don't know yet what epsilon will be. But 
anyway, this is only about improving that 1% performance hit.