Runtime: Update CI and official build to VS2019

Created on 28 Jun 2019  ·  6Comments  ·  Source: dotnet/runtime

More aggressive C/C++ optimizations done by VS2019 are breaking fragile assumptions of the CoreCLR “manually managed code”. This will need to be fixed before we can update.

The problem was found by the test job https://github.com/dotnet/coreclr/pull/25466 .

Unwinding of Frame chains accesses stack local variables after the stack frame has been unwound, but it depends on their content to be left intact. The new compiler is breaking this assumption by stack-packing a different variable over it.

The problematic pattern is:

{
     ...
     GC_PROTECT
     ...
           throw exception
     ...
     GC_PROTECT_END
     ...
}
HELPER_METHOD_FRAME_END // The GC protect frame that is out of scope is accessed by the  unwinder here.
area-ExceptionHandling-coreclr

Most helpful comment

While we still need to do a follow up fixes for VS2019, they should not be blocking this switch anymore. Feel free to go ahead and update the CI and official builds to use VS2019.

All 6 comments

This problem is causing System.Reflection.Emit.ILGeneration.Tests to crash with this stacktrace when CoreCLR is compiled by VS2019:

(5868.3b74): Access violation - code c0000005 (first/second chance not available)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
coreclr!Thread::SetFrame+0x3c3:
00007ff8`af0b598b 488b4008        mov     rax,qword ptr [rax+8] ds:00000000`00000008=????????????????
0:230> k
 # Child-SP          RetAddr           Call Site
00 0000004f`d09f0260 00007ff8`af0a0eb1 coreclr!Thread::SetFrame+0x3c3 [D:\coreclr\src\vm\threads.cpp @ 163] 
01 0000004f`d09f03c0 00007ff8`af9e34ca coreclr!UnwindAndContinueRethrowHelperInsideCatch+0x91 [D:\coreclr\src\vm\excep.cpp @ 8197] 
02 0000004f`d09f04e0 00007ff8`af822b00 coreclr!`COMCustomAttribute::CreateCaObject'::`1'::catch$5+0x188 [D:\coreclr\src\vm\customattribute.cpp @ 856] 
03 0000004f`d09f0550 00007ff8`af8214ea coreclr!_CallSettingFrame+0x20 [d:\agent\_work\1\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm @ 50] 
04 0000004f`d09f0580 00007ff9`0ec805e6 coreclr!__FrameHandler3::CxxCallCatchBlock+0x15a [d:\agent\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 1568] 
05 0000004f`d09f0620 00007ff8`af665e23 ntdll!RcFrameConsolidation+0x6 [minkernel\ntos\rtl\amd64\capture.asm @ 919] 
06 0000004f`d09fafe0 00007ff8`50fdb95e coreclr!COMCustomAttribute::CreateCaObject+0x4c3 [D:\coreclr\src\vm\customattribute.cpp @ 801] 
07 0000004f`d09fb400 00000000`00000000 0x00007ff8`50fdb95e

This is required to be able to build our IJW tests with the new toolset (and also to fix dotnet/runtime#12108).

Looks like the issue that was initially blocking the switch has been fixed. Is anything else blocking the switch to VS2019?

The fix has issues https://github.com/dotnet/corefx/pull/41280#issuecomment-535626074 . We should wait for the fix to propagate through the system and stabilize before the switch.

While we still need to do a follow up fixes for VS2019, they should not be blocking this switch anymore. Feel free to go ahead and update the CI and official builds to use VS2019.

It was ultimately fixed by dotnet/coreclr#27452

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chunseoklee picture chunseoklee  ·  3Comments

matty-hall picture matty-hall  ·  3Comments

EgorBo picture EgorBo  ·  3Comments

bencz picture bencz  ·  3Comments

omariom picture omariom  ·  3Comments