Test failure JIT\\Stress\\ABI\\pinvokes_d\\pinvokes_d.cmd

[VincentBu]

Run: runtime-coreclr outerloop 20220316.3

Failed test:

R2R-CG2 windows arm Checked no_tiered_compilation @ Windows.10.Arm64v8.Open

- JIT\\Stress\\ABI\\pinvokes_d\\pinvokes_d.cmd
- JIT\\Stress\\ABI\\pinvokes_do\\pinvokes_do.cmd

CoreCLR windows arm Checked no_tiered_compilation @ Windows.10.Arm64v8.Open

- JIT\\Stress\\ABI\\pinvokes_do\\pinvokes_do.cmd
- JIT\\Stress\\ABI\\pinvokes_d\\pinvokes_d.cmd

Error message:

Could Not Find D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\IL-CG2\composite-r2r.dll
Could Not Find D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.dll.rsp

Assert failure(PID 4900 [0x00001324], Thread: 2384 [0x0950]): !nUnwindInfoSize || !pHeap || pHeap->m_fPermitStubsWithUnwindInfo

<no module>! <no symbol> + 0x0 (0x00000000)
File: D:\a_work\1\s\src\coreclr\vm\stublink.cpp Line: 2129
Image: D:\h\w\A1550933\p\corerun.exe

Return code:      1
Raw output file:      D:\h\w\A1550933\w\B3E8099A\uploads\Reports\JIT.Stress\ABI\pinvokes_d\pinvokes_d.output.txt
Raw output:
BEGIN EXECUTION
pinvokes_d.dll
1 file(s) copied.
Response file: D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.dll.rsp
D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\IL-CG2\pinvokes_d.dll
-o:D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.dll
--targetarch:arm
--verify-type-and-field-layout
--method-layout:random
-r:D:\h\w\A1550933\p\System..dll
-r:D:\h\w\A1550933\p\Microsoft..dll
-r:D:\h\w\A1550933\p\mscorlib.dll
-r:D:\h\w\A1550933\p\netstandard.dll
-O
" "dotnet" "D:\h\w\A1550933\p\crossgen2\crossgen2.dll" @"D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.dll.rsp"   -r:D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\IL-CG2*.dll"
Emitting R2R PE file: D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.dll
"D:\h\w\A1550933\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  pinvokes_d.dll --pinvokes --num-calls 1000 --no-ctrlc-summary
Stressing pinvokes
OSVersion: Microsoft Windows NT 10.0.19041.0
OSArchitecture: Arm64
ProcessArchitecture: Arm
Selecting win86 ABI
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test Harness Exitcode is : 1
To run the test:

set CORE_ROOT=D:\h\w\A1550933\p
D:\h\w\A1550933\w\B3E8099A\e\JIT\Stress\ABI\pinvokes_d\pinvokes_d.cmd
Expected: True
Actual:   False


Stack trace
   at JIT_Stress._ABI_pinvokes_d_pinvokes_d_._ABI_pinvokes_d_pinvokes_d_cmd()

[jakobbotsch]

Small repro:

using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Runtime.Loader;

public class Program
{
    public static void Main()
    {
        CollectibleALC alc = new CollectibleALC();
        Assembly asm = alc.LoadFromAssemblyPath(Assembly.GetExecutingAssembly().Location);
        MethodInfo mi = asm.GetType(typeof(Program).FullName).GetMethod("MainInner");
        mi.Invoke(null, null);
    }

    public static void MainInner()
    {
        CalleeDelegate callee = Callee;
        callee(default);
        GC.KeepAlive(callee);
    }

    private static int Callee(S32U s)
    {
        return 0;
    }

    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    private delegate int CalleeDelegate(S32U s);

    public struct S32U { public byte F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19, F20, F21, F22, F23, F24, F25, F26, F27, F28, F29, F30, F31; }

    private class CollectibleALC : AssemblyLoadContext
    {
        public CollectibleALC() : base(true)
        {
        }
    }
}

The problem is that for collectible ALCs we end up using the heap here to place shuffle thunks:

runtime/src/coreclr/vm/loaderallocator.cpp

Line 1668 in ac84ea6

m_pShuffleThunkCache = new ShuffleThunkCache(SystemDomain::GetGlobalLoaderAllocator()->GetExecutableHeap());

This heap does not have m_fPermitStubsWithUnwindInfo set, so we hit the following assert when trying to create a shuffle thunk with unwind info:

runtime/src/coreclr/vm/stublink.cpp

Line 2129 in ac84ea6

_ASSERTE(!nUnwindInfoSize || !pHeap || pHeap->m_fPermitStubsWithUnwindInfo);

cc @janvorli @jkotas

[jakobbotsch]

I am not sure what the intention of the flag is, whether it is just to validate that we only place unwind info in expected places, or whether there is an actual problem with putting the unwind information in other heaps. From what I understand, on 64-bit the pointers to unwind information are 32-bit offsets so are relative to a base address, and thus the unwind information cannot be placed arbitrarily, so here it might be a problem. I am not sure if 32-bit has similar problems.

My question is whether the flag should be set on that heap or whether we should disable emitting unwind information for shuffle thunks in that heap. There is a todo about changing away from using that heap for shuffle thunks, so fixing that might solve the problem in a better way in the future.

[mangod9]

@AaronRobinsonMSFT could you please take a look at this. Its arm32 only so perhaps moving to 8 might be ok.

[jakobbotsch]

Its arm32 only so perhaps moving to 8 might be ok.

Not even that but it is also win-arm32 only, so moving it should definitely be fine given that this is not a supported configuration.
Also, I believe it would be fixed as a side effect of #55697.

[AaronRobinsonMSFT]

Also, I believe it would be fixed as a side effect of #55697.

Good point @jakobbotsch.

[mangod9]

Hi @jakobbotsch does this still repro?

[jakobbotsch]

We can close this one given that win-arm is unsupported and now removed from our testing.