-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shouldn't allow randomly placing ByRef-like fields #12842
Comments
If somebody does this, it will lead to silent intermittent data corruptions that are always incredibly painful to debug. How hard is this to fix? I think it would be worth fixing for 3.0. |
I just did a "file & forget" and didn't actually look at how difficult it is to fix. I'll move it to 3.0 and have a look. Cc @sergiy-k |
First approximation of a fix for #25057. This has two problems: * We're checking for any byref-like typed fields. Types that don't actually contain interior pointers but were marked as `ref struct` will fail to load when not aligned properly. * We're not doing the deep validation that we do for reference types to make sure the `ByReference<T>` field doesn't overlap with another non-byreference field. Question is whether we're okay with those limitations, or whether we need a better fix. Better fix would likely entail inefficiently walking over the fields à la `FindByRefPointerOffsetsInByRefLikeObject` (doing the more efficient thing that we do for object references below would require a GCDesc representation of byrefness). Contributes to #25057.
I fixed part of this bug described in the initial issue, but this still has a leftover piece: We currently don't check for people overlaying byref-like things with other things. So: [StructLayout(LayoutKind.Explicit)]
ref struct Broken
{
[FieldOffset(0)]
Span<int> _foo;
[FieldOffset(0)]
IntPtr _bad;
} Will load just fine, even though we would have blocked loading this if the It seems blocking this might be a good thing. We can either block this by specifically looking for One argument for not doing anything for this is that the GC doesn't actually mind if the interior pointer points at junk. So maybe we don't need to block this... Thoughts? |
I do not have a strong opinion on this. I would be ok with doing nothing. |
Happy to close then - this part was grey zone for me. The part we really cared about was fixed with dotnet/coreclr#25200. |
We should probably prevent loading types that attempt to place byref-like fields at addresses that are not divisible by pointer size.
This will print 1234/0 instead of 1234/42 (that gets printed if you remove the
StructLayout(Explicit)
).Found while messing around with dotnet/coreclr#25056.
The text was updated successfully, but these errors were encountered: