runtime: Random failures in System.Numerics.Tests.modpowTest.ModPowAxiom test

Description

When running System.Runtime.Numerics tests in a loop on wasm, like this: while true; do ./dotnet.sh build /t:Test /p:TargetOS=Browser /p:TargetArchitecture=wasm /p:Configuration=Release /p:EnableAggressiveTrimming=true /p:RunAOTCompilation=true /p:WasmNativeStrip=false src/libraries/System.Runtime.Numerics/tests/ || break; done

Sometimes there are failures:

  fail: [FAIL] System.Numerics.Tests.modpowTest.ModPowAxiom
  info: Assert.Equal() Failure
  info:            ↓ (pos 1)
  info: Expected: 524863242896023465128953873554861870122629···
  info: Actual:   546939980250394360189857941360277104885397···
  info:            ↑ (pos 1)
  info:    at System.Numerics.Tests.modpowTest.VerifyIdentityString(String opstring1, String opstring2)
  info:    at System.Numerics.Tests.modpowTest.ModPowAxiom()

The failure is not wasm specific however, happens with a console app as well.

using System;
using System.Numerics;

public class Test
{
    public static void Main () {
        byte[] tempByteArray1;
        byte[] tempByteArray2;
        byte[] tempByteArray3;

        tempByteArray1 = new byte [] { 226, 32 };
        tempByteArray2 = new byte [] { 113 };
        tempByteArray3 = new byte [] { 15, 8, 201, 158, 96, 200, 233, 243, 184, 0, 33, 203, 210, 80, 174, 198, 244, 177, 223, 221, 168, 243, 233, 133, 103, 252, 219, 195, 187, 227, 215, 54, 66, 248, 37, 186, 232, 45, 227, 147, 100, 14, 121, 244, 56, 89, 181, 120, 205, 4, 59, 48, 65, 239, 221, 28, 30, 68, 55, 99, 237, 38, 56, 213, 40, 234, 136, 218, 42, 244, 222, 198, 205 };

        var n1 = new BigInteger (tempByteArray1);
        var n2 = new BigInteger (tempByteArray2);
        var n3 = new BigInteger (tempByteArray3);

        var res1 = BigInteger.ModPow(n1, n2, n3);
        var res2 = BigInteger.Remainder (BigInteger.Pow(n1, (int)n2), n3);
        Console.WriteLine (res1);
        Console.WriteLine (res2);
    }
}

In master/net7 preview 4, this prints:

5248632428960234651289538735548618701226298035417369475266516952575810713774356752529490610201770297680688383780908963419756694889385961142585935984058777893641945433342961982
54693998025039436018985794136027710488539704291920837071192774624968986537187541952846187915666352899137283834570037293378029168944185733267466726919021367393203218220280126

while with net6, it prints:

54693998025039436018985794136027710488539704291920837071192774624968986537187541952846187915666352899137283834570037293378029168944185733267466726919021367393203218220280126
54693998025039436018985794136027710488539704291920837071192774624968986537187541952846187915666352899137283834570037293378029168944185733267466726919021367393203218220280126

So this looks like a regression which is triggered by the specific set of inputs in the test case.

Reproduction Steps

Expected behavior

Actual behavior

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

Fixed #70330 — committed to sakno/runtime by sakno 2 years ago
Fix for Random failures in System.Numerics.Tests.modpowTest.ModPowAxiom test (#74112) * Fixed #70330 * Removed pessimistic buffer cleanup — committed to dotnet/runtime by sakno 2 years ago
Fixed #70330 — committed to dotnet/runtime by sakno 2 years ago
[release/7.0-rc1] Fix for Random failures in System.Numerics.Tests.modpowTest.ModPowAxiom test (#74181) * Fixed #70330 * Removed pessimistic buffer cleanup Co-authored-by: sakno <roman.sakno@gm... — committed to dotnet/runtime by github-actions[bot] 2 years ago

Most upvoted comments

Here’s our plan on this issue:

We are still working to get a fix in place before the RC1 snap
If the fix misses the snap but lands soon thereafter, we will consider going through Tactics Ask Mode to port the fix into RC1
If the fix misses Ask Mode or is not justified for it, but it’s proven to be a regression from .NET 6, we will fix it in RC2
If the issue proves not to be a regression, we will fix it in .NET 8

jeffhandley on Aug 12, 2022

@dakersnar , @jeffhandley , PR is ready for review.

sakno on Aug 17, 2022

This is a correct output

54693998025039436018985794136027710488539704291920837071192774624968986537187541952846187915666352899137283834570037293378029168944185733267466726919021367393203218220280126

Checked in java (it doesn’t accept negative modulos, yay)

import java.math.*;

class HelloWorld {
    public static void main(String[] args) {
        
        var n1 = new BigInteger ("8418");
        var n2 = new BigInteger ("113");
        var n3 = new BigInteger ("12421714448554955886377993147779372741715160061029778448376437168219030709121226880650783927927868674313412837516053211174986358043602622119800674680911960141623475683349428209");
        
        System.out.println(n1.modPow(n2, n3));
    }
}

So .NET 6 behavior is correct. Something wrong with ModPow operation itself, because combination of public Remainder and Pow are working as expected.

sakno on Aug 17, 2022

@sakno Also, I have a more reproducible failing unit test set up here if you would like to cherry pick this commit https://github.com/dakersnar/runtime/tree/fix-70330

dakersnar on Aug 17, 2022

@dakersnar , I’ll take a look.

sakno on Aug 17, 2022