runtime: Test failure JIT\\jit64\\opt\\cse\\hugeexpr1\\hugeexpr1.cmd

Run: runtime-coreclr outerloop 20220824.6

Failed test:

R2R-CG2 windows x86 Checked no_tiered_compilation @ Windows.10.Amd64.Open

- JIT\\jit64\\opt\\cse\\hugeexpr1\\hugeexpr1.cmd

Error message:

Out of memory.

Return code:      1
Raw output file:      C:\h\w\9DB7088E\w\B91F0A66\uploads\Reports\JIT.jit64\opt\cse\hugeexpr1\hugeexpr1.output.txt
Raw output:
BEGIN EXECUTION
hugeexpr1.dll
1 file(s) copied.
3:34:27.37
Response file: C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\hugeexpr1.dll.rsp
C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\IL-CG2\hugeexpr1.dll
-o:C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\hugeexpr1.dll
--targetarch:x86
--verify-type-and-field-layout
--method-layout:random
-r:C:\h\w\9DB7088E\p\System..dll
-r:C:\h\w\9DB7088E\p\Microsoft..dll
-r:C:\h\w\9DB7088E\p\mscorlib.dll
-r:C:\h\w\9DB7088E\p\netstandard.dll
-O
" "dotnet" "C:\h\w\9DB7088E\p\crossgen2\crossgen2.dll" @"C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\hugeexpr1.dll.rsp"   -r:C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\IL-CG2*.dll"
Emitting R2R PE file: C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\hugeexpr1.dll
3:36:47.46
Crossgen2 failed with exitcode - -532462766
Test Harness Exitcode is : 1
To run the test:

set CORE_ROOT=C:\h\w\9DB7088E\p
C:\h\w\9DB7088E\w\B91F0A66\e\JIT\jit64\opt\cse\hugeexpr1\hugeexpr1.cmd
Expected: True
Actual:   False


Stack trace
   at JIT_jit64._opt_cse_hugeexpr1_hugeexpr1_._opt_cse_hugeexpr1_hugeexpr1_cmd()
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 16 (13 by maintainers)

Commits related to this issue

Most upvoted comments

I can send out a PR for adding the issues.targets entry. For the above discussion regarding test parallelization on x86, I no longer think it is related. The machines are physically x64 and even if the generated XUnit wrapper is run as an x86 app (I’m not sure about that), it’s a very short app that basically only runs separate processes for the individual test cases. These processes run in separate address spaces that shouldn’t be constrained by 32-bit considerations. I’m guessing it’s just that Crossgen2 gets too close to the 2 GB limit and there’s possibly a bit of non-determinism due to internal parallelization that probably affects the exact amount of GC memory and causes the test to pass or fail with a certain probability. We can take a closer look what exact data is causing the problem (CopiedMetadataBlobNode as suggested by the call stack shared by Anton can hardly be causing this by itself as it’s basically the MSIL metadata within the managed test binary, I don’t think that can be that big).