Closed v-wenyuxu closed 1 year ago
@dotnet/crossgen-contrib PTAL
@AaronRobinsonMSFT Could you take a look, we'll help you if there is some R2R ism that you need explained.
@davidwrighton I don't think this is very effective for me to look at this. It runs okay on Windows x64 with crossgen and runs fine on non-crossgen Windows arm64 so crossgen in some manner is busted on arm64. I'm happy to look at this but clearly there is something odd on the arm64 path in crossgen in general because x64 works without issue.
What can I get for you?
I am unable to reproduce this on x64 in any way. I've tried multiple runs with no success. Based on this I think this is likely an arm64 specific issue with CrossGen.
I am very confused by this. I couldn't reproduce it on my Arm64 Raspberry Pi either. I'll try later or tomorrow on my M1 Mac and see if by any chance I can see it there.
It is failing with AF here:
Exception type: System.Diagnostics.DebugProvider+DebugAssertException
Message: at Internal.TypeSystem.CastingHelper.CanCastToInternal(TypeDesc thisType, TypeDesc otherType, StackOverflowProtect protect) in /_/src/coreclr/tools/Common/TypeSystem/Common/CastingHelper.cs:line 179
at Internal.TypeSystem.CastingHelper.IsCompatibleWith(TypeDesc thisType, TypeDesc otherType) in /_/src/coreclr/tools/Common/TypeSystem/Common/CastingHelper.cs:line 142
at Internal.TypeSystem.MethodSignature.Equals(MethodSignature otherSignature, Boolean allowCovariantReturn) in /_/src/coreclr/tools/Common/TypeSystem/Common/MethodDesc.cs:line 238
at ILCompiler.DependencyAnalysis.ReadyToRun.TypeValidationChecker.ValidateTypeWorker(EcmaType type) in /_/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/TypeValidationChecker.cs:line 314
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
at ILCompiler.DependencyAnalysis.ReadyToRun.TypeValidationChecker.ValidateTypeWorker(EcmaType type)
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
If it is hard to repro, it can be a GC hole or intermittent codegen issue.
It is asserting because of thisType
is SignatureTypeVariable
.
If it is hard to repro, it can be a GC hole or intermittent codegen issue.
Looking at the dump, this should be very reliable repro. There are no signs of any low level corruption.
Note that the test was run with the configuration:
export RunCrossGen2=1
export DOTNET_TieredCompilation=0
export DOTNET_ForceRelocs=1
export DOTNET_ForceRelocs=1
Shoot. I missed that. I will rerun my test locally. Thanks @BruceForstall!
export DOTNET_ForceRelocs=1
Shoot. I missed that. I will rerun my test locally. Thanks @BruceForstall!
That was it. I have a local repro.
This is my bug - use after free. I don't know what the DOTNET_ForceRelocs=1
scenario does but it uncovered a real issue. I had naively assumed the ownership of memory could be handed off. In the above case the memory is freed in the inner scope and not recreated.
Note that the test was run with the configuration:
export RunCrossGen2=1 export DOTNET_TieredCompilation=0 export DOTNET_ForceRelocs=1
Oh! I hadn't set the DOTNET_ForceRelocs
environment variable. Thanks for pointing it out Bruce. I will leave things to Aaron now since the bug is in his area of expertise, but if my help is needed sometime, I'll be glad to assist.
Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices See info in area-owners.md if you want to be subscribed.
Author: | v-wenyuxu |
---|---|
Assignees: | AaronRobinsonMSFT |
Labels: | `area-System.Runtime.CompilerServices`, `blocking-clean-ci-optional` |
Milestone: | 8.0.0 |
Run: runtime-coreclr r2r-extra 20230617.1
Failed test:
Error message: