Skip to content
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

[wasm] Dispose Xunit ToolCommand #108319

Merged
merged 3 commits into from
Sep 30, 2024
Merged

[wasm] Dispose Xunit ToolCommand #108319

merged 3 commits into from
Sep 30, 2024

Conversation

ilonatommy
Copy link
Member

@ilonatommy ilonatommy commented Sep 27, 2024

Trying to fix:
#105315

Following the stack from the linked issue, we have:

_testOutput.WriteLine($"{label} {message}");

https://github.com/xunit/xunit/blob/6bfa188331f6d4ed6e877ab6da5e7b2725ccd721/src/xunit.v3.core/Framework/TestOutputHelper.cs#L45

We might be trying to WriteLine, after xunit threw an exception and the test state is already null. Do not try to log the messages (both error and info) if the command is already disposed.

@ilonatommy ilonatommy self-assigned this Sep 27, 2024
Copy link
Contributor

Tagging subscribers to this area: @directhex, @matouskozak
See info in area-owners.md if you want to be subscribed.

@ilonatommy
Copy link
Member Author

Instead of rerunning the pipeline on this PR, I would prefer to merge it asap and see how the report of known build issue changes. The change is harmless, even if it won't be the correct fix.

@pavelsavara pavelsavara changed the title Wrap xunit's WriteLine methods in try catch. [wasm] Dispose Xunit ToolCommand Sep 28, 2024
@pavelsavara
Copy link
Member

do we have the same problems in Wasi.Build.Tests ?

@ilonatommy
Copy link
Member Author

do we have the same problems in Wasi.Build.Tests ?

No, wasi was never hit in total of ~60 hits till now.

@ilonatommy
Copy link
Member Author

/ba-g the failing test is timeout with no log, typical for CI builds on windows. We cannot catch it with active issue

.WithWorkingDirectory(_projectDir!)
.ExecuteWithCapturedOutput($"build -restore -c {config} -bl:{Path.Combine(s_buildEnv.LogRootPath, $"{id}.binlog")} {extraBuildArgs} -f {targetFramework}")
.EnsureSuccessful();
cmd.WithWorkingDirectory(_projectDir!)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overriding working dir is void if we reuse the instance (which is by the way interesting idea!).

Does it have any side effects? The Dispose of ToolCommand disposes the CurrentProcess. Which happens only when the process didn't exit, which can't happen here I guess...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, thanks for pointing out. Follow up PR it is.

One side effect: runs will share the ITestOutputHelper instance, so when we do result.Output we will see output out of both runs. In this case it does not matter, first we only build, then only run. But in tests where we build twice but with different params and the check the output for Assert.Contains, it could be a problem.

sirntar pushed a commit to sirntar/runtime that referenced this pull request Oct 3, 2024
* Make sure ToolCommand instances are disposed + do not log after the disposal. 
with: @pavelsavara
@github-actions github-actions bot locked and limited conversation to collaborators Oct 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants