[dotnet-sdk-9.0.100-preview.3.24123.6] Windows SDK thrown "Non-blittable generic types cannot be marshaled" exception. #98977

Activity

1. ghost added

   needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners

   on Feb 27, 2024
2. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Feb 27, 2024
3. vcsjones

   added

   area-System.Runtime.InteropServices

   and removed

   needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners

   on Feb 27, 2024
4. github-project-automation

   added this to AppModelon Feb 27, 2024
6. AaronRobinsonMSFT commented on Feb 27, 2024

   

   AaronRobinsonMSFT

   on Feb 27, 2024

   Member

   More actions

   This regression seems to have been introduced by #97079.
7. AaronRobinsonMSFT commented on Feb 27, 2024

   

   AaronRobinsonMSFT

   on Feb 27, 2024

   Member

   More actions

   @jkotas @jkoritzinsky I've not dug into the specifics of this yet. Does anything jump out to immediately?

   /cc @manodasanW @hez2010

   The failing stack is:

   0:000> k 16
    # Child-SP          RetAddr               Call Site
   00 0000005d`2657d6d0 00007ffc`70fb03c7     KERNELBASE!RaiseException+0x6c [minkernel\kernelbase\xcpt.c @ 936] 
   01 0000005d`2657d7b0 00007ffc`71063c89     coreclr!_CxxThrowException+0x97 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 82] 
   02 0000005d`2657d810 00007ffc`70ef3637     coreclr!RealCOMPlusThrow+0x13d [D:\a\_work\1\s\src\coreclr\vm\excep.cpp @ 11623] 
   03 0000005d`2657d880 00007ffc`70ef2e3a     coreclr!`anonymous namespace'::CreateInteropILStub+0x737 [D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp @ 5051] 
   04 0000005d`2657de80 00007ffc`70f61d73     coreclr!NDirect::CreateCLRToNativeILStub+0x166 [D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp @ 5209] 
   05 0000005d`2657df40 00007ffc`70f61ef1     coreclr!GetILStubForCalli+0x3ab [D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp @ 6087] 
   06 0000005d`2657e190 00007ffc`70faab1e     coreclr!GenericPInvokeCalliStubWorker+0x91 [D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp @ 5975] 
   07 0000005d`2657e200 00007ffc`1144e822     coreclr!GenericPInvokeCalliGenILStub+0x5e [D:\a\_work\1\s\src\coreclr\vm\amd64\PInvokeStubs.asm @ 68] 
   08 0000005d`2657e2b0 00007ffc`1144e5aa     WinRT_Runtime!ABI.System.Collections.Generic.IEnumerator<Windows.Globalization.Language>.get_HasCurrent+0xd2 [D:\a\1\s\src\WinRT.Runtime\Projections\IEnumerable.net5.cs @ 705] 
   09 0000005d`2657e360 00007ffc`1144e4ce     WinRT_Runtime!ABI.System.Collections.Generic.IEnumerator<Windows.Globalization.Language>.FromAbiHelper.MoveNext+0xba [D:\a\1\s\src\WinRT.Runtime\Projections\IEnumerable.net5.cs @ 348] 
   0a 0000005d`2657e410 00007ffc`60936254     WinRT_Runtime!ABI.System.Collections.Generic.IEnumerator<System.__Canon>.MoveNext+0x1e [D:\a\1\s\src\WinRT.Runtime\Projections\IEnumerable.net5.cs @ 710] 
   0b 0000005d`2657e440 00007ffc`d90bf3fe     System_Private_CoreLib!System.Collections.Generic.List<Windows.Globalization.Language>..ctor+0x124 [_/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/List.cs @ 85] 
   0c 0000005d`2657e4a0 00007ffc`11434fd9     System_Linq!System.Linq.Enumerable.ToList<Windows.Globalization.Language>+0x6e
   0d 0000005d`2657e4f0 00007ffc`70fa9b63     ConsoleApp1!Program.<Main>$+0x49 [E:\Demos\MarshalDirectiveExceptionDemo\ConsoleApp1\Program.cs @ 4] 
   0e 0000005d`2657e540 00007ffc`70ecf1ae     coreclr!CallDescrWorkerInternal+0x83 [D:\a\_work\1\s\src\coreclr\vm\amd64\CallDescrWorkerAMD64.asm @ 100] 
   0f 0000005d`2657e580 00007ffc`70f632a4     coreclr!MethodDescCallSite::CallTargetWorker+0x21a [D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp @ 563] 
   10 (Inline Function) --------`--------     coreclr!MethodDescCallSite::Call+0xb [D:\a\_work\1\s\src\coreclr\vm\callhelpers.h @ 458] 
   11 0000005d`2657e6c0 00007ffc`70f62e26     coreclr!RunMainInternal+0x11c [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1249] 
   12 0000005d`2657e7e0 00007ffc`70f6251e     coreclr!RunMain+0xd2 [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1320] 
   13 0000005d`2657e890 00007ffc`70f29abf     coreclr!Assembly::ExecuteMainMethod+0x1ae [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1449] 
   14 0000005d`2657eb60 00007ffc`70f24898     coreclr!CorHost2::ExecuteAssembly+0x21f [D:\a\_work\1\s\src\coreclr\vm\corhost.cpp @ 349] 
   15 0000005d`2657ece0 00007ffc`e118f106     coreclr!coreclr_execute_assembly+0xd8 [D:\a\_work\1\s\src\coreclr\dlls\mscoree\exports.cpp @ 494] 
   
8. AaronRobinsonMSFT

   removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Feb 27, 2024
9. AaronRobinsonMSFT

   added this to the 9.0.0 milestone on Feb 27, 2024
10. hez2010 commented on Feb 27, 2024

    

    hez2010

    on Feb 27, 2024

    Last edited by hez2010

    Contributor

    More actions

    We added a check here to block any calli which has a generic type context and requires runtime marshalling:
    

    runtime/src/coreclr/vm/dllimport.cpp

    Line 5049 in 151982a

    && NDirect::MarshalingRequired(NULL, pStubMD->GetSig(), pSigDesc->m_pModule, &pSigDesc->m_typeContext))

    Looking at the code ABI.System.Collections.Generic.IEnumerator`1.HasCurrent in WinRT.Runtime:

    public unsafe bool HasCurrent
    {
    	get
    	{
    		byte b = 0;
    		ExceptionHelpers.ThrowExceptionForHR(_obj.Vftbl.Get_HasCurrent_1(ThisPtr, out b));
    		return b != 0;
    	}
    }

    The Get_HasCurrent_1 is a calli with signature delegate* unmanaged[Stdcall]<System.IntPtr, out byte, int> under ABI.System.Collections.Generic.IEnumerator<T>.Vftbl.Get_HasCurrent_1, so it's a calli under a generic context.

    Seems that the check here is too conservative.

    There're three possible fixes:

    • Make the check more precise so that it only throws exception for generic type that requires runtime marshalling
    • Remove the check as we are already not checking this in NativeAOT either.
    • Update CsWinRT to change the signature to delegate* unmanaged[Stdcall]<System.IntPtr, byte*, int> so that it's blittable
11. jkotas commented on Feb 27, 2024

    

    jkotas

    on Feb 27, 2024

    Member

    More actions

    delegate* unmanaged[Stdcall]<System.IntPtr, out byte, int>

    There is no generic type in this signature. Why is this check failing on it in the first place? I agree that this check needs fixing.

    Update CsWinRT to change the signature to delegate* unmanaged[Stdcall]<System.IntPtr, byte*, int> so that it's blittable

    It would be a good idea in any case. The marshalling is unnecessary and just a pure overhead.
12. jkotas commented on Feb 27, 2024

    

    jkotas

    on Feb 27, 2024

    Member

    More actions

    There is no generic type in this signature. Why is this check failing on it in the first place? I agree that this check needs fixing.

    We may want to strip the generic context when we are creating the calli cookie. Including the generic context in the calli cookie when it is not actually used by the signature prevents sharing the calli cookies for no good reason. It would not be surprised if it shows up as a perf regression in CsWinRT.
13. hez2010 commented on Feb 27, 2024

    

    hez2010

    on Feb 27, 2024

    Last edited by hez2010

    Contributor

    More actions

    Why is this check failing on it in the first place?

    The check failing because the out byte requires runtime marshalling. We do the check if the calli is called under a generic context, regardless of whether the generic type is actually used in the calli signature. Previously we didn't do this check so the out byte is not being observed as an issue.

    👍React with 👍1Reacted by Jan Kotas
14. jkotas commented on Feb 27, 2024

    

    jkotas

    on Feb 27, 2024

    Member

    More actions

    I agree with your analysis. I think we should strip the unused generic context early when creating the calli cookie: #98977 (comment) . Would you like to submit a PR with the fix?
15. hez2010 commented on Feb 27, 2024

    

    hez2010

    on Feb 27, 2024

    Last edited by hez2010

    Contributor

    More actions

    Would you like to submit a PR with the fix?

    Yes, but I'm afraid I'm not able to work on this until the next week. If it's urgent feel free to pick it up :)

    But I think stripping the unused generic context early is not a correct fix, considering this valid case:

    RefFoo<int>.Call<int>((delegate* unmanaged<ref int, int, int>)(void*)(delegate* unmanaged<int*, int, int>)&TestPIII, ref x, x));
    
    [UnmanagedCallersOnly]
    static unsafe int TestPIII(int* arg1, int arg2) => arg2;
    
    class RefFoo<T>
    {
        public unsafe static U Call<U>(void* pfn, ref int arg1, T arg2)
        {
            return ((delegate* unmanaged<ref int, T, U>)pfn)(ref arg1, arg2);
        }
    }

    All generic context is used but it will fail due to the ref int.

    Another fix is to check generic arguments only: hez2010@4b56160

    But checking generic arguments only seems weird.

    I think we can just remove the check completely as what NativeAOT does today.
    Or we can make the check more conservative to check calli without a generic context as well, because we are already disallowing runtime marshalling for UnmanagedCallerOnly and reporting a compile error in C# (would requires fixes in CsWinRT).

    @jkotas What do you think?
16. jkotas commented on Feb 27, 2024

    

    jkotas

    on Feb 27, 2024

    Last edited by jkotas

    Member

    More actions

    All generic context is used but it will fail due to the ref int.

    I think it is the desired behavior. We have said that we are not going to expand the scenarios where the built-in runtime marshaling kicks in. You example requires built-in runtime marshalling and it did not work before the change, so it should continue to not work after the change.

    👍React with 👍1Reacted by Steve
17. jkotas

    added a commit that references this issue on Feb 28, 2024

    Strip unused generic type context for VASigCookie

    ...

    This issue will close once commit f4b713e is merged into the 'main' branch.

    f4b713e
18. ghost added

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Feb 28, 2024
19. jkotas

    added a commit that references this issue on Feb 28, 2024

    Strip unused generic type context for VASigCookie

    ...

    This issue will close once commit 7b6159f is merged into the 'main' branch.

    7b6159f
20. jkotas

    closed this as completedin #99026on Mar 1, 2024
21. jkotas

    added a commit that references this issue on Mar 1, 2024

    Strip unused generic type context for VASigCookie (#99026)

    ...

    This issue will close once commit b00f084 is merged into the 'main' branch.

    b00f084
22. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Mar 1, 2024
23. Junjun-zhao commented on Mar 1, 2024

    

    Junjun-zhao

    on Mar 1, 2024

    MemberAuthor

    More actions

    Verified this issue and it has been fixed on dotnet-sdk-9.0.100-preview.2.24129.6

    👍React with 👍2Reacted by Jan Kotas and Aaron R Robinson
24. github-actions

    locked and limited conversation to collaborators on Apr 1, 2024