Bootstrap failure due to GC / PCH memory corruption

[Zack Weinberg]

Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:

> The OFFSET_TO_BIT macro in ggc-page.c computes the index of an
> object inside a 'page', avoiding an explicit division by the
> object size for performance reasons.  Instead, a multiplication
> with a pre-computed inverse is used.  The preparation of this
> inverse table makes the explicit assumption that if the object
> size exceeds the physical page size of the platform, only one
> object will exist per GC 'page'.  See compute_inverse at
> ggc-page.c:1226.
>
> This assumption holds true for all objects allocated by the
> GC proper.  However, reading in a pre-compiled header file
> results in adding its contents to the GC page pool using
> synthesized 'page table entries' that describe them.  These
> ptes, however, violate the above assumption.  In fact, for
> every 'order' of object size, one single pte spans all the
> objects of that order, even for objects whose size exceeds
> the machine page size.  See ggc_pch_read at ggc-page.c:2045.
>
> When the GC collect phase subsequently tries to mark an object
> from one of those pages, the OFFSET_TO_BIT macro can return an
> incorrect offset value, leading to clobbered memory and the
> subsequent crash.
>
> I'm not sure how to best fix this problem: either by creating
> multiple ptes per order in ggc_pch_read so that the assumption
> of one multi-page object per pte remains true, or else by
> adapting compute_inverse to work in all cases without relying
> on that assumption.  (The 'easy fix' of just removing the if
> doesn't work because the search for the inverse won't terminate
> for large object sizes.  I haven't investigated in detail why
> this is so.)

My suggestion is that you change ggc_pch_read to create multiple ptes
per order; in fact, that you create precisely the same ptes that
ggc_alloc would have if it had allocated everything from scratch.
What it's doing right now is going to cause other problems with some
things I have in mind for faster allocation and marking.

I also suggest that you find out what these objects are that are
larger than a page.  To first order there shouldn't be any.  The only
thing I've ever seen allocate more than a page at once from GC arena
was a giant dense switch statement.

zw