Repository navigation
JITted code throws NullRefException in release #56980
Description
Run on x64 Windows:
// Generated by Fuzzlyn v1.2 on 2021-07-06 09:46:44
// Seed: 16635934940619066544
// Reduced from 447.5 KiB to 0.6 KiB in 00:02:24
// Debug: Runs successfully
// Release: Throws 'System.NullReferenceException'
struct S0
{
public uint F1;
public byte F3;
public long F4;
public uint F5;
public S0(long f4): this()
{
F4 = f4;
}
}
class C0
{
public S0 F4;
}
struct S1
{
public C0 F2;
public S0 F8;
public S1(C0 f2, S0 f8): this()
{
F2 = f2;
F8 = f8;
}
}
struct S2
{
public S1 F0;
public S2(S1 f0): this()
{
F0 = f0;
}
}
public class Program
{
public static void Main()
{
S2 vr0 = new S2(new S1(new C0(), new S0(0)));
M17(ref vr0.F0.F2.F4.F1);
}
static void M17(ref uint arg2)
{
}
}Disassembly looks quite strange:
; Assembly listing for method Program:Main()
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; optimized code
; rsp based frame
; partially interruptible
; No PGO data
; 0 inlinees with PGO data; 5 single block inlinees; 0 inlinees without PGO data
; Final local variable assignments
;
; V00 OutArgs [V00 ] ( 1, 1 ) lclBlk (32) [rsp+00H] "OutgoingArgSpace"
; V01 tmp1 [V01,T02] ( 2, 4 ) ref -> rcx class-hnd exact single-def "NewObj constructor temp"
;* V02 tmp2 [V02 ] ( 0, 0 ) struct (24) zero-ref "NewObj constructor temp"
;* V03 tmp3 [V03,T01] ( 0, 0 ) struct (32) zero-ref do-not-enreg[SFB] single-def "NewObj constructor temp"
;* V04 tmp4 [V04,T03] ( 0, 0 ) struct (32) zero-ref do-not-enreg[SFB] "NewObj constructor temp"
;* V05 tmp5 [V05,T00] ( 0, 0 ) struct (24) zero-ref do-not-enreg[SFB] "Inlining Arg"
;* V06 tmp6 [V06 ] ( 0, 0 ) struct (32) zero-ref do-not-enreg[S] single-def "Inlining Arg"
;* V07 tmp7 [V07,T08] ( 0, 0 ) int -> zero-ref V02.F1(offs=0x00) P-INDEP "field V02.F1 (fldOffset=0x0)"
;* V08 tmp8 [V08,T05] ( 0, 0 ) ubyte -> zero-ref V02.F3(offs=0x04) P-INDEP "field V02.F3 (fldOffset=0x4)"
;* V09 tmp9 [V09,T06] ( 0, 0 ) long -> zero-ref V02.F4(offs=0x08) P-INDEP "field V02.F4 (fldOffset=0x8)"
;* V10 tmp10 [V10,T04] ( 0, 0 ) int -> zero-ref V02.F5(offs=0x10) P-INDEP "field V02.F5 (fldOffset=0x10)"
;* V11 tmp11 [V11,T07] ( 0, 0 ) ref -> zero-ref single-def "Big Offset Morphing"
;
; Lcl frame size = 40
G_M27646_IG01: ;; offset=0000H
4883EC28 sub rsp, 40
;; bbWeight=1 PerfScore 0.25
G_M27646_IG02: ;; offset=0004H
48B9D0C3EE8CFB7F0000 mov rcx, 0x7FFB8CEEC3D0
E89D95E35E call CORINFO_HELP_NEWSFAST
488BC8 mov rcx, rax
E8BD15FEFF call System.Object:.ctor():this
8B042500000000 mov eax, dword ptr [0000H]
;; bbWeight=1 PerfScore 4.50
G_M27646_IG03: ;; offset=0022H
4883C428 add rsp, 40
C3 ret
;; bbWeight=1 PerfScore 1.25
; Total bytes of code 39, prolog size 4, PerfScore 9.90, instruction count 8, allocated bytes for code 39 (MethodHash=cb019401) for method Program:Main()
; ============================================================cc @dotnet/jit-contrib
Activity
AndyAyersMS commentedon Aug 6, 2021
Took a quick look; proximate cause is that VN thinks the base of an indir is null, and that feeds a nullcheck, so the codegen above is the nullcheck of a null.
Now WHY VN thinks that is not immediately clear.... likely we are missing something when modelling the memory updates done earlier in the method, and so think that bit of the struct was not explicitly initialized.
AndyAyersMS commentedon Aug 9, 2021
Think the issue may originate here:
We seem to lose the fact that we're storing to the
S1field of anS2, not to theS2itself. Logically it's the same set of bits, but I think we need to preserve the bit of field seq here we've lost...?AndyAyersMS commentedon Aug 9, 2021
@sandreenko if this is similar to issues you're already working on, do you want to take this over?
sandreenko commentedon Aug 9, 2021
@sandreenko if this is similar to issues you're already working on, do you want to take this over?
sure.