System.CodeAnalysis.dll crashes building with Crossgen2

[trylek]

Command-line:

"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\corerun" "D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\crossgen2\crossgen2.dll" -r:"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\System.*.dll" -r:"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\Microsoft.*.dll" -r:"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\mscorlib.dll" -r:"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\netstandard.dll" -O --inputbubble --out:"D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\temp.ni._dll" "D:\git\runtime2\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\Microsoft.CodeAnalysis.dll"

Error message:

D:\git\runtime2\src\coreclr\src\jit\optcse.cpp:2768
Assertion failed 'IsCompatibleType(cseLclVarTyp, expTyp)' in 'Microsoft.CodeAnalysis.CommonReferenceManager`2:PropagateRecursiveAliases([Microsoft.CodeAnalysis]Microsoft.CodeAnalysis.CommonReferenceManager`2+BoundInputAssembly[],[System.Collections.Immutable]System.Collections.Immutable.ImmutableArray`1>,[Microsoft.CodeAnalysis]Microsoft.CodeAnalysis.ArrayBuilder`1>)' during 'Optimize Valnum CSEs' (IL size 311)

category:correctness
theme:ngen
skill-level:expert
cost:medium

[sandreenko]

That is an interesting case, I think we should relax the assert until we get rid of impFixupStructReturnType.
crossgen2_failure2.txt
[1054] real type is a struct, but it was retyped as a byref. [1102] kept its struct type, but the trees are the same.

[sandreenko]

@trylek can I change area to codegen?

[trylek]

@sandreenko - sure, of course. Thanks for following up on this!

[sandreenko]

@trylek could you please help me with crossgen2 debugging?
I am running the test with the following command:

"F:\git\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\corerun" "F:\git\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\crossgen2\crossgen2.dll" -r:"F:\git\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\System.*.dll" -O --inputbubble --out:"F:\git\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\temp.ni._dll" "F:\git\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\Microsoft.CodeAnalysis.dll" --codegenopt:jitnoinline=0 --codegenopt:JitDumpBeforeAfterMorph=1 --codegenopt:NoGuiOnAssert=0 --codegenopt:ContinueOnAssert=0 --codegenopt:TieredCompilation=0 --codegenopt:JitStdOutFile=%OUTPUT_FILE% --codegenopt:JitNgenDump=PropagateRecursiveAliases --codegenopt:JitDump=PropagateRecursiveAliases

but looks like --codegenopt:NoGuiOnAssert=0 is ignored, because I don't get the assert window.

But what is more important if I add --parallelism 1 then I lose JitDump, so the output file becomes empty. If I do not use the parallel option it becomes hard to catch where we are working with the problem method.
Could you please take a look and say why jitdump is disappearing?

[janvorli]

@sandreenko the --codegenopt can only set JIT options (defined in src/coreclr/src/jit/jitconfigconfigvalues.h) and the NoGuiOnAssert is not one of them.

[janvorli]

Loosing JitDump with --parallelism 1 is strange, I've just used this combination without any problem yesterday. I wonder if the compilation could have failed on something else with the --parallelism 1 before it got to compiling the function of interest. You should be able to ask crossgen2 to compile a single function only using the --singlemethodtypename and --singlemethodname. That might help.

[sandreenko]

@janvorli thank you, the problem method is Microsoft.CodeAnalysis.CommonReferenceManager2:PropagateRecursiveAliases, should --singlemethodtypenamebeMicrosoft.CodeAnalysis.CommonReferenceManager2, do I need to escape it somehow?
I am getting Error: Type 'Microsoft.CodeAnalysis.CommonReferenceManager2' not found`.

[sandreenko]

Loosing JitDump with --parallelism 1 is strange, I've just used this combination without any problem yesterday. I wonder if the compilation could have failed on something else with the --parallelism 1 before it got to compiling the function of interest

I still see the assert message with the same method name.

[janvorli]

Ah, I haven't noticed there is a generic type. That would still be expressible in general, but the problem is that the method is on a type embedded in the generic type and that's unfortunately something the type name parser in crossgen2 cannot deal with. It can deal with generic types and it can deal with embedded types, but not with those two combined. @trylek, @MichalStrehovsky please correct me if I am wrong, but I've stepped through the parsing code and I don't see how it could handle the case. I've tried
Microsoft.CodeAnalysis.CommonReferenceManager+ResolvedReference[System.__Canon,System.__Canon],Microsoft.CodeAnalysis, but in this case the parser finds a non-generic Microsoft.CodeAnalysis.CommonReferenceManager and it cannot find the ResolvedReference in it as it is in the generic variant. Microsoft.CodeAnalysis.CommonReferenceManager[System.__Canon,System.__Canon]+ResolvedReference,Microsoft.CodeAnalysis doesn't work either as the type parsing stops on the [ and cannot deal with the +ResolvedReference after that.