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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 23 May 2020 23:54:17 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 41321@debbugs.gnu.org
> 
> I think I've worked it out: it's this mingw bug:
> https://sourceforge.net/p/mingw-w64/bugs/778/

Thank you for working on this tricky problem.

FTR, I don't use that flavor of MinGW.

> On mingw, if <stdint.h> is included before/instead of stddef.h,
> alignof (max_align_t) == 16.

The problem with the order of inclusion doesn't exist in my header
files, so alignof (max_align_t) is always 16.

> However, as can be seen by the backtrace
> above, Eli's malloc only returned an 8-byte-aligned block.

Isn't that strange?  Lisp data is allocated via lmalloc, AFAIK, and
lmalloc is supposed to guarantee LISP_ALIGNMENT alignment.  Or am I
missing something?

> That's not normally a problem, because mark_maybe_object doesn't
> care about alignment; but in conjunction with the gcc behavior
> change, we rely or mark_maybe_pointer to mark the pointer, and it
> doesn't, because the pointer is not aligned to a LISP_ALIGNMENT =
> 16-byte boundary.

I still very much doubt that this has anything to do with stack
marking during GC, since I've shown in my backtrace that
current_buffer->overlays_before points to an overlay with invalid
markers.  And GC always marks buffer's overlays (and thus their
markers), as can be seen in mark_buffer.