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

GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd failed in rolling with "Large Memory Machine required" #69113

Closed
jakobbotsch opened this issue May 10, 2022 · 3 comments · Fixed by #73173
Assignees
Labels
area-GC-coreclr blocking-clean-ci Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Milestone

Comments

@jakobbotsch
Copy link
Member

Job: https://dev.azure.com/dnceng/public/_build/results?buildId=1760633&view=results
Test: https://dev.azure.com/dnceng/public/_build/results?buildId=1760633&view=ms.vss-test-web.build-test-results-tab&runId=47405440&resultId=101792&paneView=debug
Log: https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-3e33c16d75004b5c98/PayloadGroup0/1/console.c2d85ac2.log?helixlogtype=result

The log shows:

  Starting:    GC.LargeMemory.XUnitWrapper (parallel test collections = on, max threads = 4)
    GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd [FAIL]
      
      Return code:      1
      Raw output file:      C:\h\w\A70D08E8\w\B10209D6\uploads\Reports\GC.LargeMemory\API\gc\gettotalmemory\gettotalmemory.output.txt
      Raw output:
      BEGIN EXECUTION
       "C:\h\w\A70D08E8\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  gettotalmemory.dll 2048 
      Large Memory Machine required
      Test failed
      Expected: 100
      Actual: 0
      END EXECUTION - FAILED
      FAILED
      Test Harness Exitcode is : 1
      To run the test:
      > set CORE_ROOT=C:\h\w\A70D08E8\p
      > C:\h\w\A70D08E8\w\B10209D6\e\GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd
      Expected: True
      Actual:   False
      Stack Trace:
           at GC_LargeMemory._API_gc_gettotalmemory_gettotalmemory_._API_gc_gettotalmemory_gettotalmemory_cmd()
      Output:
        
        Return code:      1
        Raw output file:      C:\h\w\A70D08E8\w\B10209D6\uploads\Reports\GC.LargeMemory\API\gc\gettotalmemory\gettotalmemory.output.txt
        Raw output:
        BEGIN EXECUTION
         "C:\h\w\A70D08E8\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  gettotalmemory.dll 2048 
        Large Memory Machine required
        Test failed
        Expected: 100
        Actual: 0
        END EXECUTION - FAILED
        FAILED
        Test Harness Exitcode is : 1
        To run the test:
        > set CORE_ROOT=C:\h\w\A70D08E8\p
        > C:\h\w\A70D08E8\w\B10209D6\e\GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd

Note that we are running these in parallel and IIUC, they allocate a large chunk of memory. @dotnet/gc, is it ok to change these LargeMemory tests to succeed instead of fail on OutOfMemoryException? Or otherwise maybe we can force them to run sequentially instead?

@ghost ghost added the untriaged New issue has not been triaged by the area owner label May 10, 2022
@ghost
Copy link

ghost commented May 10, 2022

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

Job: https://dev.azure.com/dnceng/public/_build/results?buildId=1760633&view=results
Test: https://dev.azure.com/dnceng/public/_build/results?buildId=1760633&view=ms.vss-test-web.build-test-results-tab&runId=47405440&resultId=101792&paneView=debug
Log: https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-3e33c16d75004b5c98/PayloadGroup0/1/console.c2d85ac2.log?helixlogtype=result

The log shows:

  Starting:    GC.LargeMemory.XUnitWrapper (parallel test collections = on, max threads = 4)
    GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd [FAIL]
      
      Return code:      1
      Raw output file:      C:\h\w\A70D08E8\w\B10209D6\uploads\Reports\GC.LargeMemory\API\gc\gettotalmemory\gettotalmemory.output.txt
      Raw output:
      BEGIN EXECUTION
       "C:\h\w\A70D08E8\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  gettotalmemory.dll 2048 
      Large Memory Machine required
      Test failed
      Expected: 100
      Actual: 0
      END EXECUTION - FAILED
      FAILED
      Test Harness Exitcode is : 1
      To run the test:
      > set CORE_ROOT=C:\h\w\A70D08E8\p
      > C:\h\w\A70D08E8\w\B10209D6\e\GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd
      Expected: True
      Actual:   False
      Stack Trace:
           at GC_LargeMemory._API_gc_gettotalmemory_gettotalmemory_._API_gc_gettotalmemory_gettotalmemory_cmd()
      Output:
        
        Return code:      1
        Raw output file:      C:\h\w\A70D08E8\w\B10209D6\uploads\Reports\GC.LargeMemory\API\gc\gettotalmemory\gettotalmemory.output.txt
        Raw output:
        BEGIN EXECUTION
         "C:\h\w\A70D08E8\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  gettotalmemory.dll 2048 
        Large Memory Machine required
        Test failed
        Expected: 100
        Actual: 0
        END EXECUTION - FAILED
        FAILED
        Test Harness Exitcode is : 1
        To run the test:
        > set CORE_ROOT=C:\h\w\A70D08E8\p
        > C:\h\w\A70D08E8\w\B10209D6\e\GC\LargeMemory\API\gc\gettotalmemory\gettotalmemory.cmd

Note that we are running these in parallel and IIUC, they allocate a large chunk of memory. @dotnet/gc, is it ok to change these LargeMemory tests to succeed instead of fail on OutOfMemoryException? Or otherwise maybe we can force them to run sequentially instead?

Author: jakobbotsch
Assignees: -
Labels:

area-GC-coreclr, untriaged

Milestone: -

@mangod9 mangod9 removed the untriaged New issue has not been triaged by the area owner label May 12, 2022
@mangod9 mangod9 added this to the 7.0.0 milestone May 12, 2022
@mangod9
Copy link
Member

mangod9 commented May 12, 2022

yeah would make sense to make these tests more reliable by possibly ignoring OOMs. Not sure if there is a way to mark these as "skipped" within AzDO?

@AntonLapounov
Copy link
Member

@MichalStrehovsky MichalStrehovsky added the blocking-clean-ci Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms' label Jul 27, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Aug 1, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Aug 3, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Sep 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-GC-coreclr blocking-clean-ci Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants