[Tiering] System.Threading.Thread CoreFX test ThreadTests.ApartmentState_NoAttributePresent_DefaultState_Windows fails with tiering

[kouvel]

The test fails with an xunit assertion failure with tiering in CoreFX repro with release build of CoreFX and test project, which I think runs against a release CoreCLR.

@dotnet/jit-contrib

[kouvel]

Small repro used for debug coreclr + debug corefx test:

        var apartmentState = Thread.CurrentThread.GetApartmentState();
        if (apartmentState != ApartmentState.MTA)
        {
            Console.WriteLine($"Unexpected result (expected ApartmentState.MTA): {apartmentState}");
            return;
        }

        try
        {
            Thread.CurrentThread.SetApartmentState(ApartmentState.STA);
            Console.WriteLine("Unexpected success (no exception): 'Thread.CurrentThread.SetApartmentState(ApartmentState.STA)'");
            return;
        }
        catch (InvalidOperationException)
        {
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Unexpected exception during 'Thread.CurrentThread.SetApartmentState(ApartmentState.STA)': {ex}");
        }

        try
        {
            Thread.CurrentThread.SetApartmentState(ApartmentState.MTA);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Unexpected exception during 'Thread.CurrentThread.SetApartmentState(ApartmentState.MTA)': {ex}");
        }

[kouvel]

PR to temporarily disable test: dotnet/corefx#31523

[kouvel]

Also, the test (small repro above and the System.Threading.Thread CoreFX tests) does not fail with only COMPlus_JITMinOpts=1, but it fails with COMPlus_TieredCompilation=1.

[RussKeldorph]

@dotnet/jit-contrib

[AndyAyersMS]

I can repro with the small example (say tiering vs minopts), and have done a bit of instrumentation in the runtime to see when it tries to get or set apartment state, but no real insights to offer yet.

I wonder if this is somehow tied into the observation I made the other day that tier0 is bypassed for some methods from System.Private.CoreLib, an this perhaps impacts the order of initialization or something -- that is with tiering we now run a mixture of prejitted, tier1 and tier0 code that doesn't match what we see with minopts, which only runs prejitted and tier0 code, or full opts, which only runs prejitted and tier1 code.

So perhaps there is some side effect the jit can cause via the jit interface that impacts the thread apartment state and this plays out differently in the mixed tier0/tier1 case than in the pure tier0 or pure tier1 cases. Or perhaps some initialization is done in a different order.

Will keep looking.

[AndyAyersMS]

Here's a guess:

• when tiering is enabled: tiering manager starts up a timer thread early, and this is set to be an MTA thread, and that implicitly makes the other threads (like the main thread) in the process MTA. Some in-between checks then think the main thread is already MTA and don't bother to try and set it to explicit MTA. Subsequently when the program sets the apartment state to STA this succeeds because the implicit MTA can be overridden.

• when tiering is not enabled: the main thread is unknown state and eventually gets explicitly set to MTA. Then when the program tries to set it to STA this fails and we get an (expected) exception.

So some in-between bit of logic is possibly not being sufficiently careful to distinguish between implict MTA and explicit MTA.

At any rate this doesn't look like a jit issue so will retag as runtime-ish.

Could also be a test bug I suppose.

@kouvel @noahfalk hope this helps.

[kouvel]

Ah ok, thanks @AndyAyersMS, I'll take a closer look and see how the apartment state of the main thread is being affected.

There was also an assertion failure in the JIT when using debug coreclr, it may be unrelated to the apartment state.

[AndyAyersMS]

Ah I overlooked that part -- I'll try and repro the assertion failure.

[jkotas]

when tiering is enabled: tiering manager starts up a timer thread early, and this is set to be an MTA thread, and that implicitly makes the other threads (like the main thread) in the process MTA. Some in-between checks then think the main thread is already MTA and don't bother to try and set it to explicit MTA

We may want to fix this by explicitly setting the main thread to MTA. It will also improve the compatibility with desktop. We have issue on it already: https://github.com/dotnet/coreclr/issues/17822

[AndyAyersMS]

I can't repro the jit assert -- let me know if you still see this.

I tried running the System.Threading.Thread tests on a debug build of CoreFx at 724ffde with tiering enabled, using a checked jit from CoreCLR at c62976e.

[kouvel]

I'm also not able to repro the assertion failure after syncing to latest