Console.ForegroundColor deadlocks Console on OSX

[lduchosal]

Description

The console is locked with the following conditions :

Thread dotnet/core#1. Console.WriteLine
Thread dotnet/core#2. Console.ForegroundColor locks and never returns
Thread dotnet/core#3. Console.ReadLine is locked and never returns

Problem on NET Core OSX version 3.1.200. Works on Windows x64.

Expected

Thread dotnet/core#1. Console.WriteLine
Thread dotnet/core#2. Console.ForegroundColor returns
Thread dotnet/core#3. Console.ReadLine returns

Code to reproduce

`

class Program
{
    static void Main(string[] args)
    {

        // remove this line to workaround the bug
        Console.WriteLine(@"Program.Main, try a few times to reproduce the issue");

        var wait1 = new AutoResetEvent(false);
        var wait2 = new AutoResetEvent(false);
        
        Task.Factory.StartNew(() =>
        {
            Console.ForegroundColor = ConsoleColor.Green;
            Console.WriteLine("never happens");
            Console.ResetColor();
            
            wait1.Set();
        });

        Task.Factory.StartNew(() =>
        {
            var line = Console.ReadLine();
            Console.WriteLine("never happens");
            wait2.Set();
        });

        WaitHandle.WaitAll(new[] {wait1, wait2});
        Console.WriteLine("never happens");

    }
}

`

environnement

SDK .NET Core (reflétant tous les global.json) :
Version: 3.1.200
Commit: c5123d973b

Environnement d'exécution :
OS Name: Mac OS X
OS Version: 10.15
OS Platform: Darwin
RID: osx.10.15-x64
Base Path: /usr/local/share/dotnet/sdk/3.1.200/

Host (useful for support):
Version: 3.1.2
Commit: 916b5cba26

.NET Core SDKs installed:
3.1.200 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Thanks for your help.

[tmds]

@danmosemsft I had a look at this issue.

There is a deadlock happening here between Console.Out and Console.InternalSyncObject.

Task setting Console.ForegroundColor:

-> lock (Console.InternalSyncObject)
System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef)
System.Threading.LazyInitializer.EnsureInitializedCore[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef, System.Object ByRef, System.Func`1<System.__Canon>)
System.Threading.LazyInitializer.EnsureInitialized[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef, System.Object ByRef, System.Func`1<System.__Canon>)
System.Console.get_IsOutputRedirected()

System.ConsolePal.WriteResetColorString()
-> lock (Console.Out)
System.ConsolePal.RefreshColors(System.ConsoleColor ByRef, System.ConsoleColor)

System.Console.set_ForegroundColor(System.ConsoleColor)

Task calling Console.ReadLine:

-> lock (Console.Console.Out)
System.Threading.Monitor.Enter(System.Object, Boolean ByRef)
System.ConsolePal.EnsureInitializedCore()
System.ConsolePal.get_StdInReader()
System.ConsolePal.GetOrCreateReader()
System.Console+<>c.<get_In>b__14_0()

-> lock (InternalSyncObject)
System.Threading.LazyInitializer.EnsureInitializedCore[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef, System.Object ByRef, System.Func`1<System.__Canon>)
System.Threading.LazyInitializer.EnsureInitialized[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef, System.Object ByRef, System.Func`1<System.__Canon>)
System.Console.get_In()

System.Console.ReadLine()

[tmds]

Probably we want to continue EnsureInitializedCore when someone gets Console.In.

EnsureInitializedCore locks Console.Out because it writes to stdout.

So the fix should be to ensure no-one holds Console.Out lock while performing LazyInitializer.EnsureInitialized.

I'll look into making this change.

[tmds]

So the fix should be to ensure no-one holds Console.Out lock while performing LazyInitializer.EnsureInitialized.

Actually, the user may also hold Console.Out and trigger LazyInitializer.EnsureInitialized. So there is no way to avoid that.

We can't call EnsureInitializedCore under LazyInitializer.EnsureInitialized.

[stephentoub]

From a quick peek, most of the lazily-initialized members could be done optimistically, without a lock and just with a compare-exchange to substitute in the results. A few of them might be more complicated, though.