-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
classloader/StaticVirtualMethods/GenericContext/GenericContextTest takes very long under GC stress, times out on OSX-arm64 #104633
Labels
area-TypeSystem-coreclr
blocking-clean-ci-optional
Blocking optional rolling runs
GCStress
test-failure
Milestone
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
An area label is needed to ensure this gets routed to the appropriate area owners
label
Jul 9, 2024
dotnet-policy-service
bot
added
the
untriaged
New issue has not been triaged by the area owner
label
Jul 9, 2024
steveisok
added a commit
to steveisok/runtime
that referenced
this issue
Jul 10, 2024
As suggested in dotnet#104633, this may help in reducing test timeouts.
vcsjones
removed
the
needs-area-label
An area label is needed to ensure this gets routed to the appropriate area owners
label
Jul 11, 2024
This is blocking clean gcstress runs. I think this should be fixed in 9.0 |
Should be fixed by #104686 |
Sadly, the test seems to keep running, taking 4+ hours on osx-arm64, and failing in every https://dev.azure.com/dnceng-public/public/_build?definitionId=112&_a=summary |
VSadov
pushed a commit
to VSadov/runtime
that referenced
this issue
Jul 29, 2024
As suggested in dotnet#104633, this may help in reducing test timeouts.
VSadov
added a commit
that referenced
this issue
Jul 30, 2024
* Set GCStressIncompatible on GenericContext tests As suggested in #104633, this may help in reducing test timeouts. * Update src/tests/Loader/classloader/StaticVirtualMethods/GenericContext/GenericContextCommonCs.csproj Co-authored-by: Vladimir Sadov <vsadov@microsoft.com> * Put suppression on tests exe projects, not on the common library. --------- Co-authored-by: Steve Pfister <stpfiste@microsoft.com> Co-authored-by: Steve Pfister <steveisok@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-TypeSystem-coreclr
blocking-clean-ci-optional
Blocking optional rolling runs
GCStress
test-failure
Examples of timeout failures:
https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-103076-merge-7269229228744033b5/Loader.2.3/1/console.f932d39f.log?helixlogtype=result
https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-85694-merge-c093b64e9e7a4971aa/Loader.1.3/1/console.60c249dc.log?helixlogtype=result
https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-85694-merge-c093b64e9e7a4971aa/Loader.2.3/1/console.a7c2f169.log?helixlogtype=result
Since this is always on a different scenario, I think it is just the test takes too long on OSX-arm64 machines.
Possibly the machines are too slow and the test is too big.
(the test was mentioned before as very large and causing trouble due to size in other contexts - #92722)
If there is no something that is particularly interesting from GC stress perspective for this test, perhaps we should just do
<GCStressIncompatible>true</GCStressIncompatible>
The text was updated successfully, but these errors were encountered: