Test failures in hashing on Browser #69806
Assignees
Labels
arch-wasm
WebAssembly architecture
area-System.Security
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Milestone
Comments
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsBoth of these tests are testing the hash of one million ASCII lowercase a characters. Having run through hashes of It seems like, somehow, bad data got into the pipeline... it's not a case of too much, or too little. Also noteworthy is that each of these failed in the allocating one-shots over streams (
|
|
@bartonjs were you testing in the exact same environment as the test? Ubuntu, amd64, WasmTestOnNodeJs? |
|
Any chance it's concurrency related? Concurrent test execution? |
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsBoth of these tests are testing the hash of one million ASCII lowercase a characters. Having run through hashes of It seems like, somehow, bad data got into the pipeline... it's not a case of too much, or too little. Also noteworthy is that each of these failed in the allocating one-shots over streams (
|
|
@radical can you also keep an eye on any failures in the hashing tests to make sure we know the status here |
No. Windows/amd64/Console, as an attempt to reproduce the values reported as 'actual' by the failures. (Crack the hash... crypto mining for flyweights) private static void Main()
{
IncrementalHash hash = IncrementalHash.CreateHash(HashAlgorithmName.SHA1);
byte[] buf = new byte[1024];
buf.AsSpan().Fill((byte)'a');
int count = 0;
const int Target1 = 0;
while (count < Target1)
{
int len = Math.Min(Target1 - count, buf.Length);
hash.AppendData(buf.AsSpan(0, len));
count += len;
}
const int Target2 = 5_000_000;
//ReadOnlySpan<byte> matchSHA256 = stackalloc byte[] { 156, 156, 59 };//, 215, 224 };
//ReadOnlySpan<byte> matchSHA1 = stackalloc byte[] { 217, 73, 231 };//, 108, 115, 7, 236, 194, 62, 42 };
// This is the right answer, to test that it reports a hit at i=1_000_000
ReadOnlySpan<byte> matchSHA1 = stackalloc byte[] { 52, 170, 151, 60, 212, 196, 218, 164, 246, 30 };
ReadOnlySpan<byte> match = matchSHA1;
ReadOnlySpan<byte> oneA = buf.AsSpan(0, 1);
Span<byte> hashOut = stackalloc byte[128];
for (int i = count; i < Target2; i++)
{
hash.TryGetCurrentHash(hashOut, out int written);
if (hashOut.Slice(0, match.Length).SequenceEqual(match))
{
Console.WriteLine($"Partial hit at i={i}");
}
hash.AppendData(oneA);
}
} |
I didn't think wasm had concurrency... |
The test is running on chrome, and not nodejs. |
|
https://github.com/dotnet/runtime/pull/69815/checks?check_run_id=6615945253 probably related to this |
|
this is very odd:
|
|
Hm at column 70388: I tried to always throw an exception in I tried a little patch, in case it seems useful in general: |
|
Another instance, build: |
24 tasks
|
Another hit on today's rolling build #20220531.2. |
agocke
added
the
blocking-clean-ci
|
This is failing regularly in CI -- can we add test retries or disable the test, assuming there's no fix at the moment? |
|
Another failure on: https://github.com/dotnet/runtime/pull/70065/checks?check_run_id=6699909171 |
ghost
added
the
in-pr
eerhardt
added a commit
to eerhardt/runtime
that referenced
this issue
Jun 3, 2022
When sending a message between LibraryChannel and ChannelWorker, there is a race condition where both threads are reading/writing to shared memory at the same time. This can cause message pages to be skipped. To fix this, add a shared mutex lock so only one side is reading/writing to shared memory at the same time. Fix dotnet#69806
|
Another hit on #20220606.48 |
eerhardt
added a commit
that referenced
this issue
Jun 7, 2022
When sending a message between LibraryChannel and ChannelWorker, there is a race condition where both threads are reading/writing to shared memory at the same time. This can cause message pages to be skipped. To fix this, add a shared mutex lock so only one side is reading/writing to shared memory at the same time. Fix #69806
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-69668-merge-9dd411182c95433daa/WasmTestOnBrowser-System.Security.Cryptography.Tests/1/console.fdc2faf5.log?helixlogtype=result
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-69786-merge-4202b33d23d54c99bd/WasmTestOnBrowser-System.Security.Cryptography.Tests/1/console.99f7714c.log?helixlogtype=result
Both of these tests are testing the hash of one million ASCII lowercase a characters.
Having run through hashes of
{},{'a'},{'a', 'a'}, all the way up to 5 million, for both SHA-1 and SHA-2-256, I can't reproduce either of these error values.It seems like, somehow, bad data got into the pipeline... it's not a case of too much, or too little.
Also noteworthy is that each of these failed in the allocating one-shots over streams (
public static byte[] HashData(Stream), and the async variant), after successfully doing it via other methods.The text was updated successfully, but these errors were encountered: