-
Notifications
You must be signed in to change notification settings - Fork 5.2k
load msquic early to avoid interference with RemoteExecutor #75424
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
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsWhen msquic is loaded it will also initialize While the problem really lives in I wrote I had test runs over nigh and I did not see any problems on system where it was failing before.
|
|
Could you please re-enable disabled tests?
|
src/libraries/System.Net.Requests/tests/System.Net.Requests.Tests.csproj
Outdated
Show resolved
Hide resolved
jkotas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise
|
Run tests in loop since yesterday and still looks good. macOS test failures are unrelated. |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3039384318 |
When msquic is loaded it will also initialize
lttng. That callswaitand it can reap processes fromRemoteExecutorand that will cause Assert inProcesscode. (long story and evidence is in #74795)While the problem really lives in
lttngthere is no quick fix for that. To void the problem this change tries to loadMsQuicearly via static variable and that will initializelttngbefore any tests actually start.I wrote
GetIsQuicSupportedso we can do more there if needed. e.g. call some msquic API to load everything permanently. It is not needed at this point so I left it out.I had test runs over nigh and I did not see any problems on system where it was failing before.
fixes #74795