-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Fix for Random failures in System.Numerics.Tests.modpowTest.ModPowAxiom test #74112
Conversation
Tagging subscribers to this area: @dotnet/area-system-numerics |
Updated the title -- issue numbers in titles don't work well when looking at lists of PR's 😸 |
.NET 7 port needed? |
@danmoseley , I I think yes, .NET 7 port is needed because without the fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, nice catch. Thanks for the fix!
@@ -464,7 +472,7 @@ private const | |||
power >>= 1; | |||
} | |||
|
|||
return result.Slice(0, resultLength); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this slice basically unnecessary in all cases, and causing problems in this edge case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, correct. It doesn't exist for overload of PowCore
with exponent of arbitrary length.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this slice introduced a regression for the case of:
value: 174475926811173371108797680334274448482027679060635889276326576767485928691470272416521788770673419883076040463212449631887959313694345475337324466914914839368969988215395980439434099840700753576299320684517028939674493640310781015739837159625716992654178036326745036841619965661654305787656989089177185300627
exponent: 152266387011071825363527751452194927195391511201743678326712300944812006670853968954038119879530327815990523885596782666640476470053822766345969220504425389995206265094671158964311234812226260664473986637197447367726400093404731405598815953979171704175885394570388678952091206779039984338579147114424357147650
modulus: 15548277136038299103
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this scenario, the length of result
is greater than the length of bits
and so the result.CopyTo(bits)
operation fails as the destination is too short.
I expect the actual issue here is that resultLength
isn't being correctly tracked somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its not that resultLength
is incorrect, its that bits
will have been mutated and may contain temporary data
src/libraries/System.Runtime.Numerics/src/System/Numerics/BigIntegerCalculator.PowMod.cs
Show resolved
Hide resolved
@danmoseley Yes, I'd like to get this in for .NET 7, as this is a regression from .NET 6. |
/backport to release/7.0-rc1 |
Started backporting to release/7.0-rc1: https://github.com/dotnet/runtime/actions/runs/2885517952 |
Fixes #70330