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
Seems to be a one-off failure, where a copy/execute have collided. I'm not sure whether this is within the product, or a test-fixture copy step that raced with the test execution. I was unable to reproduce the failure in master or maryamariyan:ref-src branches locally.
I believe this is like a file-in-use situation on Linux. Does the test or product code need to account for such a file-in-use? Often times these are one-off but common enough to require mitigations (virus scanners, search indexers).
@ericstj I completely agree with your assessment; I'm just trying to get a repro for this failure to see where the race could have happened.
The AppHost creation involves a few edits of the executable, and has had a few runins with anti-virus scanners. But I don't know of any AVs running on the linux test machines. The proposed fix for the AppHost issue is: #3829 and #3828.
But at least on the surface, this doesn't look like the same problem:
Every failure in the apphost writer (or when executing the host) I've seen so far has a stack trace that shows a failure when accessing something within the product.
In this case the failure was in System.Diagnostics.Process.ForkAndExecProcess(). That is, the SDK/bundler (GenerateBundle) steps have completed (which would rule out the above mentioned issues).
The AppHost spews an error trace when a failure occurs while processing the bundle contents. There's actually no indication that the host got to run at all.
This stack trace may indicate a race in the test-infrastructure -- ex: between writing the single-file app and running it. But we need more repros to be actionable.
Activity
swaroop-sridhar commentedon Mar 17, 2020
Seems to be a one-off failure, where a copy/execute have collided. I'm not sure whether this is within the product, or a test-fixture copy step that raced with the test execution. I was unable to reproduce the failure in master or
maryamariyan:ref-srcbranches locally.ericstj commentedon Mar 17, 2020
I believe this is like a file-in-use situation on Linux. Does the test or product code need to account for such a file-in-use? Often times these are one-off but common enough to require mitigations (virus scanners, search indexers).
swaroop-sridhar commentedon Mar 17, 2020
@ericstj I completely agree with your assessment; I'm just trying to get a repro for this failure to see where the race could have happened.
The AppHost creation involves a few edits of the executable, and has had a few runins with anti-virus scanners. But I don't know of any AVs running on the linux test machines. The proposed fix for the AppHost issue is: #3829 and #3828.
But at least on the surface, this doesn't look like the same problem:
System.Diagnostics.Process.ForkAndExecProcess(). That is, the SDK/bundler (GenerateBundle) steps have completed (which would rule out the above mentioned issues).This stack trace may indicate a race in the test-infrastructure -- ex: between writing the single-file app and running it. But we need more repros to be actionable.