You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CLR crashing when running RemoteExecutor tests locally on Debug builds #90485
Using the latest commit (007cbcf) on windows-x64, running:
.\build.cmd clr+libs -rc release
dotnet test src/libraries/System.Text.Json/tests/System.Text.Json.SourceGeneration.Tests/System.Text.Json.SourceGeneration.Roslyn4.4.Tests.csproj -f net8.0
Will fail with the following stacktrace:
The active test run was aborted. Reason: Test host process crashed : Fatal error. Internal CLR error. (0x80131506)
at System.Runtime.Serialization.SerializationGuard.<ThrowIfDeserializationInProgress>g__ThrowIfDeserializationInProgress|0_0(System.Runtime.Serialization.SerializationInfo, System.String, Int32 ByRef)
at System.Runtime.Serialization.SerializationGuard.ThrowIfDeserializationInProgress(System.String, Int32 ByRef)
at System.Diagnostics.Process.Start()
at System.Diagnostics.Process.Start(System.Diagnostics.ProcessStartInfo)
at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(System.Reflection.MethodInfo, System.String[], Microsoft.DotNet.RemoteExecutor.RemoteInvokeOptions, Boolean)
at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(System.Action, Microsoft.DotNet.RemoteExecutor.RemoteInvokeOptions)
at System.Text.Json.SourceGeneration.Tests.JsonSerializerContextTests.JsonSerializerContext_GeneratedDefault_IsSingleton()
at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(System.Object, IntPtr*)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(System.Object, System.Reflection.BindingFlags)
at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
at System.Reflection.MethodBase.Invoke(System.Object, System.Object[])
at Xunit.Sdk.TestInvoker`1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].CallTestMethod(System.Object)
Which seems to be originating from this call in Process.Start:
This test has started failing on my local machine in the last few days, but strangely I don't see it impacting CI. Thought I'd file an issue in case others are having the same problem.
I wouldn't be surprised if this is hardware-specific. It isn't reproducing in CI after all. Is there any chance this code might use AVX-512 instructions? I recently caught this issue with the same device that was eluding our CI builds.
Oh interesting. I missed that this is Debug for libraries. Let me try that.
Nope. Runs without issue on Debug as well.
Test run for ...\runtime\artifacts\bin\System.Text.Json.SourceGeneration.Roslyn4.4.Tests\Debug\net8.0\System.Text.Json.SourceGeneration.Roslyn4.4.Tests.dll (.NETCoreApp,Version=v8.0)
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Results File: ...\runtime\artifacts\bin\System.Text.Json.SourceGeneration.Roslyn4.4.Tests\Debug\net8.0\TestResults\arobins_AROBINS-SERVER7_2023-08-14_09_00_31.trx
Html test results file : ...\runtime\artifacts\bin\System.Text.Json.SourceGeneration.Roslyn4.4.Tests\Debug\net8.0\TestResults\TestResult_arobins_AROBINS-SERVER7_20230814_090119.html
Passed! - Failed: 0, Passed: 5801, Skipped: 0, Total: 5801, Duration: 47 s - System.Text.Json.SourceGeneration.Roslyn4.4.Tests.dll (net8.0)
Is there any chance this code might use AVX-512 instructions?
Hmmm. That would be interesting. The signature referenced in #89706, below, is rather benign and I don't see why AVX-512 would matter here.
For whatever reason, the error has stopped reproducing on my affected machine starting today. I was about to close the issue if it weren't for #90485 (comment)
@cincuranet Are the failures reproducible? Do you know the types of machines in the lab? Perhaps we can find a pattern with the machine @eiriktsarpalis was seeing failures on.
A general note here. I took the bits from @eiriktsarpalis and ran them on my machine without issue. I also tried a few JIT stress options without much success. What we need here is a DMP of the crash.
The logs I posted above are from Windows.10.Amd64.Client.Open Helix queue. That's the VMs in Azure. But it's also happening on physical machines in Windows.10.Amd64.19H1.Tiger.Perf (Intel CPU). It seems to happen every run, though different benchmarks/scenarios.
Activity
stephentoub commentedon Aug 13, 2023
@eiriktsarpalis, you've cleaned and rebuilt from root?
Presumably related to #89706
eiriktsarpalis commentedon Aug 13, 2023
Yes, the repo was cleaned before building.
stephentoub commentedon Aug 13, 2023
What does a checked runtime build show? Does it assert?
eiriktsarpalis commentedon Aug 13, 2023
stephentoub commentedon Aug 13, 2023
cc: @jkotas, @AaronRobinsonMSFT (I assume this is to do with UnsafeAccessor)
4 remaining items
eiriktsarpalis commentedon Aug 14, 2023
I wouldn't be surprised if this is hardware-specific. It isn't reproducing in CI after all. Is there any chance this code might use AVX-512 instructions? I recently caught this issue with the same device that was eluding our CI builds.
AaronRobinsonMSFT commentedon Aug 14, 2023
Nope. Runs without issue on
Debugas well.Hmmm. That would be interesting. The signature referenced in #89706, below, is rather benign and I don't see why AVX-512 would matter here.
eiriktsarpalis commentedon Aug 14, 2023
It's not reproing on my devbox either.
eiriktsarpalis commentedon Aug 14, 2023
I'll see if a can do a bisect and pinpoint the precise regression point.
eiriktsarpalis commentedon Aug 14, 2023
It's not reproing in ef900fa, this probably started later. I'll start a bisect but it while take a while...
AaronRobinsonMSFT commentedon Aug 14, 2023
Thanks @eiriktsarpalis. Until we prove otherwise, I will leave this on VM and keep myself assigned.
cincuranet commentedon Aug 15, 2023
Similar crash is happening now in dotnet/performance for (SDK) scenarios. Here or here is an example log.
eiriktsarpalis commentedon Aug 15, 2023
For whatever reason, the error has stopped reproducing on my affected machine starting today. I was about to close the issue if it weren't for #90485 (comment)
AaronRobinsonMSFT commentedon Aug 15, 2023
@cincuranet Are the failures reproducible? Do you know the types of machines in the lab? Perhaps we can find a pattern with the machine @eiriktsarpalis was seeing failures on.
A general note here. I took the bits from @eiriktsarpalis and ran them on my machine without issue. I also tried a few JIT stress options without much success. What we need here is a DMP of the crash.
cincuranet commentedon Aug 15, 2023
The logs I posted above are from
Windows.10.Amd64.Client.OpenHelix queue. That's the VMs in Azure. But it's also happening on physical machines inWindows.10.Amd64.19H1.Tiger.Perf(Intel CPU). It seems to happen every run, though different benchmarks/scenarios.DrewScoggins commentedon Aug 18, 2023
We are also seeing this now in our RC1 performance runs. This is from our microbenchmark run on Windows.