net8 JIT locks up in unit tests when calling into WPF

[FlsZen]

Description

While updating from net7 to net8, a couple of my unit tests started deadlocking. It looks like they deadlock in JIT while accessing System.Windows types.

Reproduction Steps

1. Open attached Deadlock.sln
2. Run the tests in Deadlock-net8 until failure

Deadlock.zip

Expected behavior

Running Deadlock-net8 tests should be successful each time.

Actual behavior

I observe it deadlocking at least every few runs.

Regression?

This works on net7. Run the tests in Deadlock-net7 until failure to observe.

Known Workarounds

Using xUnit Collection attributes to disable parallelization gets the test to run.

Impact

I'm concerned that this JIT / assembly loading issue could cause deadlocks at runtime.

While my test cases are narrowed to calling a WPF assembly, I'm not yet convinced that it isn't a runtime issue. I did try calling into a custom stub assembly instead of WPF and the tests ran fine. I'm not sure if the issue could be related to something like how long it takes the assembly to load or some other non-WPF criteria.

Configuration

.NET 8.0.0
Windows 11 x64
Unsure if specific to this configuration, but net7 runs the tests fine on the OS.

Other information

No response

[czdietrich]

We experience a very similar problem since migrating to .NET 8. The issue also occurs for us when running unit tests, but with the difference that it only happens when also collecting code coverage is switched on. (dotnet test --collect "Code Coverage")

On the first glance, it looks like WPF is not involved in our case, but main parts of the call stack look fairly close to yours.

Maybe this is a general .NET issue and we should move it to the dotnet/runtime repo.

[lindexi]

@czdietrich Do you create the issues in dotnet/runtime repo?

[czdietrich]

I hoped we could just move this issue, since @FlsZen has already attached repro steps.
For us the issue happens for our business application which is not open source, so creating useful reproduction steps that can be shared easily may be most probably time consuming.
Nevertheless I could share a memory dump of the hanging process internally.

[czdietrich]

Could we consider to bump up the priority of this issue? We still experience that problem even without collecting code coverage.
There are still no reproduction steps we can share publicly, but we could probably share memory dumps of the deadlocked processes internally, if requested.

[miloush]

@singhashish-wpf could you move this to dotnet/runtime?

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[JulieLeeMSFT]

CC @dotnet/jit-contrib.

[AndyAyersMS]

The JIT does not take any locks by itself, so this is more likely a runtime issue.