JIT crash/assert while compiling Grpc.core codebase #57535
Assignees
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
davidwrighton
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsRepro instructions: Using that directory as the working directory, run crossgen2 passing the rsp file in the zip as a response file. For example:
If run against a Debug crossgen2, it will produce an assert If run against a release crossgen2 it will produce an AV
|
JulieLeeMSFT
removed
the
untriaged
JulieLeeMSFT
added
the
needs-further-triage
|
You can also repro this by grabbing Grpc.Core and Grpc.Core.Api 2.38 from nuget, extracting the DLLs, and running PMI: |
|
Issue is that |
|
Suspect cloning gets confused because and so likely cloning thinks V01 is an int? |
|
Not clear yet how to fix this... |
EgorBo
added a commit
to EgorBo/runtime-1
that referenced
this issue
Aug 17, 2021
|
I wonder if a naive fix would help EgorBo@cde5dd5 (well, it does, but how legal it is...) |
|
Simple repro: using System;
using System.Runtime.CompilerServices;
class X
{
static long z;
public static int Main()
{
z = 10;
int[] a = F();
long zz = z;
int result = 0;
for (int i = 0; i < (int) zz; i++) result += a[i];
return result;
}
[MethodImpl(MethodImplOptions.NoInlining)]
static int[] F()
{
int[] result = new int[100];
result[3] = 100;
return result;
}
}w/default behavior: |
The other approach would be to abandon cloning in a case like this, that seems a bit safer perhaps. Testing this now. |
AndyAyersMS
removed
the
needs-further-triage
|
FYI @JulieLeeMSFT -- we need to fix this for .NET 6 but it's not going to make the RC1 deadline. Should have a fix ready by tomorrow. |
Or give up on labeling loops (Seems to not produce SPMI diffs too which is nice) |
|
Bailing out in cloning @ -968,7 +968,14 @@ bool Compiler::optDeriveLoopCloningConditions(unsigned loopNum, LoopCloneContext
else if (loop->lpFlags & LPFLG_VAR_INIT)
{
// initVar >= 0
- LC_Condition geZero(GT_GE, LC_Expr(LC_Ident(loop->lpVarInit, LC_Ident::Var)),
+ const unsigned initLcl = loop->lpVarInit;
+ if (lvaGetDesc(initLcl)->lvType != TYP_INT)
+ {
+ JITDUMP("> Init var V%02u not TYP_INT\n", initLcl);
+ return false;
+ }
+
+ LC_Condition geZero(GT_GE, LC_Expr(LC_Ident(initLcl, LC_Ident::Var)),
LC_Expr(LC_Ident(0, LC_Ident::Const)));
context->EnsureConditions(loopNum)->Push(geZero);
}
@@ -992,9 +999,15 @@ bool Compiler::optDeriveLoopCloningConditions(unsigned loopNum, LoopCloneContext
}
else if (loop->lpFlags & LPFLG_VAR_LIMIT)
{
- unsigned limitLcl = loop->lpVarLimit();
- ident = LC_Ident(limitLcl, LC_Ident::Var);
+ const unsigned limitLcl = loop->lpVarLimit();
+
+ if (lvaGetDesc(limitLcl)->lvType != TYP_INT)
+ {
+ JITDUMP("> Limit var V%02u not TYP_INT\n", limitLcl);
+ return false;
+ }
+ ident = LC_Ident(limitLcl, LC_Ident::Var);
LC_Condition geZero(GT_GE, LC_Expr(ident), LC_Expr(LC_Ident(0, LC_Ident::Const)));
context->EnsureConditions(loopNum)->Push(geZero);produces 2 diffs |
|
In the 75579 case the limit var is a |
|
Similar for 114034, a |
AndyAyersMS
added a commit
to AndyAyersMS/runtime
that referenced
this issue
Aug 17, 2021
The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes dotnet#57535.
ghost
added
the
in-pr
We can backport to RC1 as servicing. |
|
@JulieLeeMSFT go ahead and port a fix to release/6.0 and we can then consider for RC1 |
AndyAyersMS
added a commit
that referenced
this issue
Aug 18, 2021
The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes #57535.
ghost
removed
the
in-pr
github-actions bot
pushed a commit
that referenced
this issue
Aug 18, 2021
The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes #57535.
github-actions bot
pushed a commit
that referenced
this issue
Aug 18, 2021
The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes #57535.
jeffschwMSFT
pushed a commit
that referenced
this issue
Aug 19, 2021
…cal (#57685) * JIT: don't clone loops where init or limit is a cast local The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes #57535. * Apply suggestions from code review Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com> Co-authored-by: Andy Ayers <andya@microsoft.com> Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
jeffschwMSFT
pushed a commit
that referenced
this issue
Aug 19, 2021
…t local (#57690) * JIT: don't clone loops where init or limit is a cast local The loop cloner assumes all computations it introduces are compatible with TYP_INT, so don't allow cloning when the initial or final value are variables with incompatible types. Fixes #57535. * Apply suggestions from code review Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com> Co-authored-by: Andy Ayers <andya@microsoft.com> Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Repro instructions:
Download https://microsoft-my.sharepoint.com/:u:/p/davidwr/ETDI552L1RtCugwcniHGv5QBVsNi3PDCpXt6y-tWayhvow?e=f4wH4F and unzip it to a directory.
Using that directory as the working directory, run crossgen2 passing the rsp file in the zip as a response file. For example:
c:\git\runtime\dotnet c:\git\runtime\artifacts\bin\coreclr\windows.x64.Debug\crossgen2\crossgen2.dll @crossgen2repro.rspIf run against a Debug crossgen2, it will produce an assert
If run against a release crossgen2 it will produce an AV
The text was updated successfully, but these errors were encountered: