Description
This is a duplicate of #42375 as far as symptoms and behavior go but I am still encountering the exact same symptoms on 5.0.400. I can reproduce this on Mac OS and Windows.
When debugging, our dev team encounters sporadic hangs (about 30% of the time). There does not seem to be any specific reproducible pattern of when in the program execution the hang occurs. When it happens, the diagnostics logger stops updating
and I cannot break or terminate the program:
If I try to dotnet trace collect on a hung process, dotnet trace hangs as well.
I have tried taking and analyzing a memory dump using wpr as described here, but I have not been able to find anything meaningful.
Configuration
Reproduced on 5.0.400 on Mac OS and Windows. In Visual Studio and Rider IDE.
Regression?
This issue seems to have started when we upgraded from netcoreapp3.1 to net5.0
Other information
The amount of logging and amount of asynchronous operations seems to make the issue more/less prevalent. For example, turning down the log level makes the issue happen about 20% of the time instead of 30% of the time.
Description
This is a duplicate of #42375 as far as symptoms and behavior go but I am still encountering the exact same symptoms on 5.0.400. I can reproduce this on Mac OS and Windows.
When debugging, our dev team encounters sporadic hangs (about 30% of the time). There does not seem to be any specific reproducible pattern of when in the program execution the hang occurs. When it happens, the diagnostics logger stops updating
and I cannot break or terminate the program:
If I try to
dotnet trace collecton a hung process,dotnet tracehangs as well.I have tried taking and analyzing a memory dump using wpr as described here, but I have not been able to find anything meaningful.
Configuration
Reproduced on 5.0.400 on Mac OS and Windows. In Visual Studio and Rider IDE.
Regression?
This issue seems to have started when we upgraded from netcoreapp3.1 to net5.0
Other information
The amount of logging and amount of asynchronous operations seems to make the issue more/less prevalent. For example, turning down the log level makes the issue happen about 20% of the time instead of 30% of the time.