Add issues.targets entry for known issue #84007 #84268
Conversation
ghost
added
the
area-CodeGen-coreclr
|
/azp run runtime-coreclr outerloop |
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue Detailsnull
|
|
Azure Pipelines successfully started running 1 pipeline(s). |
markples
left a comment
markples
left a comment
There was a problem hiding this comment.
I just looked at the known build error formatting, and it looks like it isn't possible say "R2R only". Am I reading that correctly? (which supports exactly what you did here with issues.targets and a conditional)
|
I'm not aware of any standardized way to indicate in the issues themselves to what platforms or test modes they pertain, their formatting is completely informal, the only way to correlate issues with runtimes, platforms and build modes is the conditional item groups in issues.targets; it's been under discussion for a while because it's quite annoying to maintain (and it has grown substantially with mono) but we haven't made any fundamental change to the mechanism yet. We basically presume that after merging all tests and removing the legacy infrastructure we could transform issues.targets annotations into ActiveIssue attributes on the individual tests but it's easier said than done - as you can easily see, MSBuild script flexibility far exceeds what can be specified in ActiveIssue and the ability to temporarily block a larger group of tests (like a subfolder) at once is also handy at times. I would be happy to see us end up with a hybrid solution - for longer term blockings we'd use ActiveIssue annotations but we'd keep the option to use much reduced issues.targets for temporary emergencies. |
|
Link: #84007 |
|
@BruceForstall - thanks for the approval. Interestingly enough those jobs that have already finished are showing failures in two more tests,
and
I have looked at git history and neither of these tests have been touched in years. The error message seems to indicate something around JIT, have you got any idea how to route this apparently new bug or what needs fixing in Crossgen2? Thanks Tomas Unhandled exception. ILCompiler.CodeGenerationFailedException: Code generation failed for method '[rank1array].Main()' ---> System.NotImplementedException: CORINFO_HELP_NEW_MDARR_RARE at Internal.JitInterface.CorInfoImpl.GetHelperFtnUncached(CorInfoHelpFunc ftnNum) in //src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs:line 1098 at Internal.JitInterface.CorInfoImpl.getHelperFtn(CorInfoHelpFunc ftnNum, Void*& ppIndirection) in //src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs:line 3257 at Internal.JitInterface.CorInfoImpl.getHelperFtn(IntPtr thisHandle, IntPtr* ppException, CorInfoHelpFunc ftnNum, Void** ppIndirection) in //src/coreclr/tools/Common/JitInterface/CorInfoImpl_generated.cs:line 1944 --- End of inner exception stack trace --- at Internal.JitInterface.CorInfoImpl.CompileMethodInternal(IMethodNode methodCodeNodeNeedingCode, MethodIL methodIL) in //src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs:line 383 at Internal.JitInterface.CorInfoImpl.CompileMethod(MethodWithGCInfo methodCodeNodeNeedingCode, Logger logger) in //src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs:line 659 at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass46_0.g__CompileOneMethod|5(DependencyNodeCore1 dependency, Int32 compileThreadId) in /_/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs:line 841 at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass46_0.g__CompileOnThread|4(Int32 compilationThreadId) in /_/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs:line 775 at ILCompiler.ReadyToRunCodegenCompilation.<>c__DisplayClass46_0.g__CompileMethodList|2(IEnumerable1 methodList) in //src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs:line 735 at ILCompiler.ReadyToRunCodegenCompilation.ComputeDependencyNodeDependencies(List1 obj) in /_/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs:line 659 at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer2.ComputeMarkedNodes() in //src/coreclr/tools/aot/ILCompiler.DependencyAnalysisFramework/DependencyAnalyzer.cs:line 316 at ILCompiler.ReadyToRunCodegenCompilation.Compile(String outputFile) in //src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs:line 343 at ILCompiler.Program.RunSingleCompilation(Dictionary2 inFilePaths, InstructionSetSupport instructionSetSupport, String compositeRootPath, Dictionary2 unrootedInputFilePaths, HashSet`1 versionBubbleModulesHash, ReadyToRunCompilerContext typeSystemContext) in //src/coreclr/tools/aot/crossgen2/Program.cs:line 616 at ILCompiler.Program.Run() in //src/coreclr/tools/aot/crossgen2/Program.cs:line 289 at ILCompiler.Crossgen2RootCommand.<>c__DisplayClass187_0.<.ctor>b__0(InvocationContext context) in //src/coreclr/tools/aot/crossgen2/Crossgen2RootCommand.cs:line 293 at System.CommandLine.Invocation.AnonymousCommandHandler.Invoke(InvocationContext context) at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Invocation.InvocationPipeline.g__FullInvocationChain|3_0(InvocationConte |
|
OK, I see now this may be related to a very recent change by @MichalStrehovsky. |
|
I'll be happy to contribute to implementing the new JIT interface helpers but I could use a bit of guidance regarding what is Crossgen2 supposed to do here. One way or another I believe the failures are unrelated to my issues.targets-only change. |
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Sorry about that! That change split off a rare IL-only part of an existing helper into a new helper. I don't think it makes sense to add handling to R2R for it since it can only be reached in IL. I've added a commit to turn it into RequiresRuntimeJit and re-triggered the pipeline. |
|
I have verified that the browser-wasm errors are caused by and are unrelated to my and Michal's changes, merging in. |
4 participants
No description provided.