-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[NativeAOT] Assert when compiling System.Runtime.Tests #73027
Comments
CC: @MichalStrehovsky - this is with current bits in main. |
The logic is new (#71485) - I don't think it's severe - I think you can just comment it out locally to unblock yourself. Cc @vitek-karas |
It happens on win-x64 as well |
There is a similar assert in // Scans the method as well as any nested functions (local functions or lambdas) and state machines
// reachable from it.
public virtual void InterproceduralScan(MethodIL startingMethodBody)
{
MethodDesc startingMethod = startingMethodBody.OwningMethod;
Debug.Assert(startingMethod.IsTypicalMethodDefinition);
// We should never have created a DataFlowAnalyzedMethodNode for compiler generated methods
// since their data flow analysis is handled as part of their parent method analysis.
Debug.Assert(!CompilerGeneratedState.IsNestedFunctionOrStateMachineMember(startingMethod)); I am guessing if I comment one, I will start hitting the other. |
after commenting the assert in both places tests can build and pass. |
Thanks for finding this Vlad. The short version is that we haven't ported all of the functionality from linker yet - in this case specifically the "Reflection access to compiler generated methods". The situation of this repro:
void UserMethod()
{
if (AlwaysFalse) // Or a feature switch which will evaluate to constant false
{
LocalFunction();
}
void LocalFunction() { do something which requires data flow }
}
I'll look into the fix some more - there's also an interesting question regarding warning behavior in this case (both for linker and AOT). /cc @sbomer |
See the test for description of what it does. It's basically the linker repro for the case hit in dotnet/runtime#73027 (comment)
… code. The problem occurs when an entire type/assembly is preserved through explicit rooting (command line, rd.xml, ...). If such type contains a local function (for example) which is only called from a branch which is going to be removed by constant-prop/branch removal the internal tracking of compiler generated methods will see this local function as orphaned (not belonging to any user method). This leads to a case where we will try to run data flow on the local function - but that should never happen for compiler generated methods directly -> assert. The fix is (just like in the linker), to never run data flow on compiler generated methods directly - they should only run data flow as part of their respective user method. Fixes dotnet#73027
See the test for description of what it does. It's basically the linker repro for the case hit in dotnet/runtime#73027 (comment)
… code. (#73085) The problem occurs when an entire type/assembly is preserved through explicit rooting (command line, rd.xml, ...). If such type contains a local function (for example) which is only called from a branch which is going to be removed by constant-prop/branch removal the internal tracking of compiler generated methods will see this local function as orphaned (not belonging to any user method). This leads to a case where we will try to run data flow on the local function - but that should never happen for compiler generated methods directly -> assert. The fix is (just like in the linker), to never run data flow on compiler generated methods directly - they should only run data flow as part of their respective user method. Fixes #73027
The assert happens with current bits from main.
I hoped that it could be somehow caused by the barrier issue that was fixed in #72919.
However the assert reproduces after the fix has been merged and appears to be deterministic.
It looks like it is happening in the constructor of
DataflowAnalyzedMethodNode
To repro, compile runtime and tests on a linux-arm64 machine like:
The failure is not specific to linux-arm64
win-x64 repro:
The text was updated successfully, but these errors were encountered: