Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Fix use of uninitialized variables in managed decimal implementation #25674

Merged
merged 2 commits into from
Jul 13, 2019

Conversation

jkotas
Copy link
Member

@jkotas jkotas commented Jul 13, 2019

I have noticed that decimal multiplications and divisions return bogus results intermittently while working on unrelated issues. It turns out a few places in the new managed decimal implementation use uninitialized stack variables. I have added debug-only instrumentation to catch these.

@jkotas
Copy link
Member Author

jkotas commented Jul 13, 2019

The CoreFX tests have not hit this problem because of the stacklayout from XUnit is very predictable with the specific stack locations all typically being zero by luck.

@jkotas
Copy link
Member Author

jkotas commented Jul 13, 2019

@MeiChin-Tsai Could you please approve this change?

@@ -156,6 +156,13 @@ private ulong Low64
1e80
};

// Used to fill uninitialized stack variables with non-zero pattern in debug builds
[System.Diagnostics.Conditional("DEBUG")]
private static unsafe void Poison<T>(ref T s) where T: unmanaged
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: maybe DebugPoison so the debug-only-ness is clearer at call site?

@stephentoub
Copy link
Member

I have added debug-only instrumentation to catch these.

Would it make sense for the future to add a mode for the JIT where non-initlocals are poisoned in a similar way?

@jkotas
Copy link
Member Author

jkotas commented Jul 13, 2019

Yes, that would make sense - especially if the skipinitlocals becomes more mainstream. Filled https://github.com/dotnet/coreclr/issues/25683

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants