runtime: System.Composition: Bug in Resolving Activators Due to the .NET Type System
I have been tracking down a pretty nasty bug today in regards to System.Composition. After a discussion about this on StackOverflow, I have decided to open an issue here in hopes to get additional conversation/context/insight around this.
Essentially, there appears to be a race condition when accessing System.Reflection elements for the first time from different threads. In the case of System.Composition, it relies on a ParameterInfo object when determining an activator to use for a dependency.
Due to the issue as explained above in StackOverflow, the ParameterInfo object may or may not be the expected key at this point, since the stored ParameterInfo in the CompositionDependency.Site.Parameter may or may not be the same object that gets returned after the value has been initialized and cached in the System.Reflection system.
About this issue
- Original URL
- State: open
- Created 8 years ago
- Comments: 32 (13 by maintainers)
Commits related to this issue
- Test for Issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Fix for issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Test for Issue #6857 modified to improve the rate of triggering the race condition — committed to jswolf19/corefx by jswolf19 7 years ago
- Test for Issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Fix for issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Test for Issue #6857 modified to improve the rate of triggering the race condition — committed to jswolf19/corefx by jswolf19 7 years ago
- Test for Issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Fix for issue #6857 — committed to jswolf19/corefx by jswolf19 7 years ago
- Test for Issue #6857 modified to improve the rate of triggering the race condition — committed to jswolf19/corefx by jswolf19 7 years ago
- System.Composition Activator parameter initialization race condition (#21312) * Test for Issue #6857 * Fix for issue #6857 * Test for Issue #6857 modified to improve the rate of triggering the ... — committed to dotnet/corefx by jswolf19 7 years ago
Sounds good. If it’s too time-consuming, it might have to be marked [Outerloop] but other than that, testing by stressing the code paths sounds reasonable to me.
@AlexGhiondea No worries. I can finally build again without dotnet crashing ^_^ I imagine things are busy.
Taking into account @AtsushiKan’s advice, I’d still like to add a non-deterministic test, unless no test at all is preferred. I seem to be able to trigger the race condition fairly consistently even with just two tasks on my machine if I’m running only the Composition tests, so I’ll see if it’ll fail from
build-tests. If so, I’ll createEnvironment.ProcessorCounttasks to increase the odds of failure on a multi-core machine and then add in the fix.@AlexGhiondea can you please help as area expert/owner? I have never seen the code base before, so I can’t comment.
In general: I would recommend to split it into 2 parts/phases or even 2 bugs - one specific and one “find similar instances”.
Ok, I’ve opened https://github.com/dotnet/corefx/issues/8130. Maybe the “Future” milestone is only visible to MS people – I’m not sure.
Oh yes, my mind skipped a step there. The bug in Composition has been acknowledged, but not yet fixed. Too early to close the issue.
It appears the original issue has been fixed in System.Composition by removing the assumption that ParameterInfo is a valid key. The caching of reflection objects such as ParameterInfo are driven by performance and memory consumption desires, not as a promise that it can be used to establish semantic identity.
The question of whether Reflection should offer a more complete “comparison” story is an interesting one but it’s not an RTM issue.
ParameterInfodoes not have anyEqualsorGetHashCodeimplementation. It is not clear how to even check for equality. This suggests reference equality semantics. Therefore I think the best solution is to ensure uniqueness at the .NET BCL level.Adding @nguerrera and @AtsushiKan who might know a little bit more about it.
@pallavit Is the behavior encountered here expected, where in multithreaded scenarios the ParameterInfos you get from different calls to GetParameters() may not compare as equal or have the same hash code?