CompositionContainer is not thread safe - even when constructed as thread safe

[nick-beer]

Our application makes extensive use of the System.ComponentModel.Composition libraries and uses the CompositionContainer from many different threads. When the container is created, it is marked (via the constructor) as thread safe.

We've successfully used the container like this in .NET Framework 4.6.2 for many many years, but with a recent update to .NET 5, we're seeing some crashes.

Specifically, the path along CompositionContainer.Compose() does not look thread safe. We eventually get to RecompositionManager.GetAffectedParts, and while enumerating the alive items list, an exception is thrown because a different thread has modified that list. The other thread is in the middle of satisfying a call to GetExportedValue. Examination of the crashing stack reveals that there is no locking around the modified members.

Here's a snapshot of the stack that crashes:

The crash has been seen against .NET 5 (runtime version 5.0.9) and .NET 6 (runtime version 6.0.0-rc.1.21451.13).

Here is a (relatively) simple single file c# program that will reliably reproduce the crash we're seeing.

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

Issue Details

---

Our application makes extensive use of the System.ComponentModel.Composition libraries and uses the CompositionContainer from many different threads. When the container is created, it is marked (via the constructor) as thread safe.

We've successfully used the container like this in .NET Framework 4.6.2 for many many years, but with a recent update to .NET 5, we're seeing some crashes.

Specifically, the path along CompositionContainer.Compose() does not look thread safe. We eventually get to RecompositionManager.GetAffectedParts, and while enumerating the alive items list, an exception is thrown because a different thread has modified that list. The other thread is in the middle of satisfying a call to GetExportedValue. Examination of the crashing stack reveals that there is no locking around the modified members.

Here's a snapshot of the stack that crashes:

The crash has been seen against .NET 5 (runtime version 5.0.9) and .NET 6 (runtime version 6.0.0-rc.1.21451.13).

Here is a (relatively) simple single file c# program that will reliably reproduce the crash we're seeing.

Author:	nick-beer
Assignees:	-
Labels:	area-System.Threading, untriaged
Milestone:	-

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

Issue Details

---

Our application makes extensive use of the System.ComponentModel.Composition libraries and uses the CompositionContainer from many different threads. When the container is created, it is marked (via the constructor) as thread safe.

We've successfully used the container like this in .NET Framework 4.6.2 for many many years, but with a recent update to .NET 5, we're seeing some crashes.

Specifically, the path along CompositionContainer.Compose() does not look thread safe. We eventually get to RecompositionManager.GetAffectedParts, and while enumerating the alive items list, an exception is thrown because a different thread has modified that list. The other thread is in the middle of satisfying a call to GetExportedValue. Examination of the crashing stack reveals that there is no locking around the modified members.

Here's a snapshot of the stack that crashes:

The crash has been seen against .NET 5 (runtime version 5.0.9) and .NET 6 (runtime version 6.0.0-rc.1.21451.13).

Here is a (relatively) simple single file c# program that will reliably reproduce the crash we're seeing.

Author:	nick-beer
Assignees:	-
Labels:	area-System.Composition, untriaged
Milestone:	-

[nick-beer]

It's worth noting this is not a regression from .NET Framework. I initially thought that it was, but I built the example app linked above against .NET Framework 4.7.2 (obviously modifying the code to have a main etc), and got the same crash. It looked like the code along the Compose path hasn't really changed much - so it makes sense that the issue is in both .NET Framework and .NET. I'm not sure why the crash is just now showing up in our .NET 5 build, but this is a significant/worrisome issue for our applications we're migrating to .NET 5.

[joperezr]

Thanks for the very complete report of the issue @nick-beer! I'm also wondering why if this wasn't a regression you started seeing the issue after migrating to .NET from .NET Framework, and were not seeing this before.