You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On i686-unknown-linux-gnu, the metadata spec mmtk::util::metadata::side_metadata::spec_defs::MS_FREE (aliased as mmtk::policy::marksweepspace::native_ms::block::Block::FREE_LIST_TABLE) has the offset.rel_offset field holding the value 150081 (0x24a41) which is not 4-byte aligned. As a result, its meta_addr is 0x40024a41 on the DummyVM. It will be an error when loading the free list pointer (usize which is 4 bytes) from that metadata using unaligned pointer. The error passed silently on Rust 1.66.1, but will panic on 1.71.0 because of unaligned pointer access.
If the MS_FREE metadata is intended to store 4-byte elements, the metadata itself should be 4-byte aligned. Since the metadata specs are constants, the bug should be in the computing of the relative offset or the starting address of the metadata.
The text was updated successfully, but these errors were encountered:
The reason is that the CHUNK_MARK local side metadata occupies only one byte per chunk, and local metadata are allocated in a per-chunk basis. That caused subsequent local side metadata to be misaligned.
`align_offset_alloc` and related functions now use
`ptr::{read,write}_unaligned` to access the prepended address.
When calculating the address or offset of metadata, we ensure its
address or offset is at least word-aligned.
Fixes: #886Fixes: #888
---------
Co-authored-by: Yi Lin <qinsoon@gmail.com>
On i686-unknown-linux-gnu, the metadata spec
mmtk::util::metadata::side_metadata::spec_defs::MS_FREE
(aliased asmmtk::policy::marksweepspace::native_ms::block::Block::FREE_LIST_TABLE
) has theoffset.rel_offset
field holding the value 150081 (0x24a41) which is not 4-byte aligned. As a result, itsmeta_addr
is 0x40024a41 on the DummyVM. It will be an error when loading the free list pointer (usize
which is 4 bytes) from that metadata using unaligned pointer. The error passed silently on Rust 1.66.1, but will panic on 1.71.0 because of unaligned pointer access.If the
MS_FREE
metadata is intended to store 4-byte elements, the metadata itself should be 4-byte aligned. Since the metadata specs are constants, the bug should be in the computing of the relative offset or the starting address of the metadata.The text was updated successfully, but these errors were encountered: