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
{{ message }}
This repository was archived by the owner on Jun 10, 2024. It is now read-only.
The issue here presented as tuples printing off the end of their
elements array by some large arbitrary amount. This was happening
because the memory we allocated for a tuple included space for the
pointer metadata (the size) we need to restore fat pointers for tuples
in Rust, so we would offset the base pointer of the allocation by
`mem::size_of::<usize>()` bytes and return _that_ as the pointer to the
tuple, and in cases where we were decoding the tuple, we'd subtract the
offset to read the metadata and then use the metadata to restore a fat
pointer.
The problem here, is that by offsetting the pointer we allocated, we
were changing the alignment of the pointer, and the new alignment was
not 16 bytes, but 8, and therefore when encoding as an OpaqueTerm, the
low 4 bits of the pointer were being masked off, effectively encoding a
pointer to the base of the allocation, rather than to the start of the
tuple elements. Then, when any mutation of a tuple involving the first
element of the tuple occurred, it would overwrite the capacity metadata
with an OpaqueTerm value, then any subsequent traversal of the tuple
elements would think it was walking a tuple of like 9 billion elements.
The solution here is simple, we have no good reason to offset the
pointer we're encoding as a term, so instead we change the definition of
Tuple to make it clear that the base of the struct includes the capacity
metadata, and update all code that cares about the layout of the Tuple
struct to be aware of this new layout. The pointers are properly
aligned, and we don't have to worry about accidentally overwriting the
metadata any longer.
NOTE: This problem isn't present with Closure or BinaryData, which are
also unsized types, because they already made their metadata field
explicit in the struct definition.
This fixes the issue with the global_dynamic_call test.
0 commit comments