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

[Bug]: Investigate why IdenticalSubmissionsShouldCompleteAndNotHangTheBuildOnMissingTargetExceptions started failing #9245

Closed
ladipro opened this issue Sep 21, 2023 · 0 comments · Fixed by #9253
Labels
Area: Our Own Build Problems affecting the build or build infrastructure of the MSBuild repo itself. bug triaged

Comments

@ladipro
Copy link
Member

ladipro commented Sep 21, 2023

Issue Description

The test started failing on PR CI pipeline. Suspecting timing issues.

Steps to Reproduce

https://dev.azure.com/dnceng-public/public/_build/results?buildId=414226&view=results

Expected Behavior

Test is reliable.

Actual Behavior

Test fails in PR builds.

Analysis

No response

Versions & Configurations

No response

@ladipro ladipro added bug needs-triage Have yet to determine what bucket this goes in. labels Sep 21, 2023
@AR-May AR-May added Area: Our Own Build Problems affecting the build or build infrastructure of the MSBuild repo itself. and removed needs-triage Have yet to determine what bucket this goes in. labels Sep 26, 2023
JaynieBai pushed a commit that referenced this issue Oct 11, 2023
…ngTargetExceptions (#9253)

Fixes #9245

Context
The test was disabled to unblock PR CI.

Changes Made
Increased the relevant timeout.

Testing
The test is reliably passing now.

Notes
This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process:

image

We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough.

I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine.

EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.
bulatgrzegorz pushed a commit to bulatgrzegorz/selective-condition-evaluator that referenced this issue Oct 16, 2023
…ngTargetExceptions (dotnet#9253)

Fixes dotnet#9245

Context
The test was disabled to unblock PR CI.

Changes Made
Increased the relevant timeout.

Testing
The test is reliably passing now.

Notes
This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process:

image

We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough.

I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine.

EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.
MichalPavlik pushed a commit that referenced this issue Oct 17, 2023
…ngTargetExceptions (#9253)

Fixes #9245

Context
The test was disabled to unblock PR CI.

Changes Made
Increased the relevant timeout.

Testing
The test is reliably passing now.

Notes
This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process:

image

We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough.

I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine.

EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Our Own Build Problems affecting the build or build infrastructure of the MSBuild repo itself. bug triaged
Projects
None yet
2 participants