[wasm] Wasm.Build.Tests xharness crash: "There is no currently active test."
#55999
Assignees
Labels
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
Tagging subscribers to this area: Issue Details
|
radical
added a commit
to radical/runtime
that referenced
this issue
Jul 22, 2021
.. when the process ends. `BuildTestBase.RunProcess` subscribes to messages from stdout/stderr. It seems that sometimes after the process is done, and the test has also ended, the streams might still be flushing messages, and ends up invoking our stdout/stderr message handlers. And these handlers call xunit's `ITestOutputHelper.WriteLine`, which then fails with: ``` System.InvalidOperationException: There is no currently active test. at Xunit.Sdk.TestOutputHelper.GuardInitialized() in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\TestOutputHelper.cs:line 51 at Xunit.Sdk.TestOutputHelper.QueueTestOutput(String output) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\TestOutputHelper.cs:line 66 at Wasm.Build.Tests.BuildTestBase.<>c__DisplayClass37_0.<RunProcess>g__LogData|2(String label, String message) in /_/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs:line 569 at System.Diagnostics.AsyncStreamReader.FlushMessageQueue(Boolean rethrowInNewThread) in System.Diagnostics.Process.dll:token 0x6000098+0x87 --- End of stack trace from previous location --- at System.Diagnostics.AsyncStreamReader.<>c.<FlushMessageQueue>b__18_0(Object edi) in System.Diagnostics.Process.dll:token 0x600009f+0x0 at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute() in System.Private.CoreLib.dll:token 0x6002a84+0x14 at System.Threading.ThreadPoolWorkQueue.Dispatch() in System.Private.CoreLib.dll:token 0x6002a5f+0x10a at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() in System.Private.CoreLib.dll:token 0x6002b39+0x6c at System.Threading.Thread.StartCallback() in System.Private.CoreLib.dll:token 0x60026db+0xe ``` Note: I couldn't actually reproduce this, so this change is just to be defensive, and hopefully fix this issue. Fixes: dotnet#55999
ghost
added
the
in-pr
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
radical
changed the title
Wasm.Build.Tests xharness crash: "There is no currently active test."
ghost
removed
the
in-pr
radical
added a commit
to radical/runtime
that referenced
this issue
Jul 29, 2021
Earlier commit[1] tried to fix the [issue](dotnet#55999) where messages would be received from a process that had exited, but after the test was complete. The exception in that case: ``` System.InvalidOperationException: There is no currently active test. at Xunit.Sdk.TestOutputHelper.GuardInitialized() in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\TestOutputHelper.cs:line 51 at Xunit.Sdk.TestOutputHelper.QueueTestOutput(String output) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\TestOutputHelper.cs:line 66 at Wasm.Build.Tests.BuildTestBase.<>c__DisplayClass37_0.<RunProcess>g__LogData|2(String label, String message) in /_/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs:line 569 at System.Diagnostics.AsyncStreamReader.FlushMessageQueue(Boolean rethrowInNewThread) in System.Diagnostics.Process.dll:token 0x6000098+0x87 --- End of stack trace from previous location --- at System.Diagnostics.AsyncStreamReader.<>c.<FlushMessageQueue>b__18_0(Object edi) in System.Diagnostics.Process.dll:token 0x600009f+0x0 at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute() in System.Private.CoreLib.dll:token 0x6002a84+0x14 at System.Threading.ThreadPoolWorkQueue.Dispatch() in System.Private.CoreLib.dll:token 0x6002a5f+0x10a at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() in System.Private.CoreLib.dll:token 0x6002b39+0x6c at System.Threading.Thread.StartCallback() in System.Private.CoreLib.dll:token 0x60026db+0xe ``` But that commit didn't quite fix the issue, and we now get dotnet#56513 , where we still end up missing last few lines. The reason seems to be that we use `process.WaitForExit(timeout)`, and once that returns, we return from the method. But the documentation[2] suggests that we need to call `process.WaitForExit()` after this, to ensure that all the async event handlers get called. It should mean that we are not stopping the event handlers early. Fixes: dotnet#56513 -- 1. ``` commit ec2d25c Author: Ankit Jain <radical@gmail.com> Date: Wed Jul 28 12:35:23 2021 -0400 [wasm] Wasm.Build.Tests - try to close down the stdout/err readers (dotnet#56180) ``` 2. https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.waitforexit?view=net-6.0#System_Diagnostics_Process_WaitForExit_System_Int32_ ``` When standard output has been redirected to asynchronous event handlers, it is possible that output processing will not have completed when this method returns. To ensure that asynchronous event handling has been completed, call the WaitForExit() overload that takes no parameter after receiving a true from this overload. ```
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://dev.azure.com/dnceng/public/_build/results?buildId=1248297&view=ms.vss-test-web.build-test-results-tab&runId=37078550&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-55955-merge-df508acdb75840a58a/EMSDK-Wasm.Build.Tests/console.4429ff13.log?sv=2019-07-07&se=2021-08-09T14%3A09%3A49Z&sr=c&sp=rl&sig=H%2BE9ltDz7FuP717ePuXO2wnb0M35hgrRFN%2FFAnvQI44%3D
The text was updated successfully, but these errors were encountered: