DryIoc: Deadlock during Resolve
I’ve run into a weird deadlock when resolving one of the services manually.
First short background - we’re using DryIoc in a WPF app, and it’s working very nicely for us right now. As part of some concept work I’m trying to run the code as a netcoreapp3.1 console app. All of our registration code is being reused for this, so the container contents are very similar to what we have in WPF. The app resolves and configures some things and then one of the resolves deadlocks. I updated to 4.7.5 and it still happens, the call stack looks like this:
System.Private.CoreLib.dll!System.Threading.SpinWait.SpinOnceCore(int sleep1Threshold) Line 197 C#
DryIoc.dll!DryIoc.Scope.WaitForItemIsSet(ImTools.ImMapEntry<object> itemRef) Line 12019 C#
DryIoc.dll!DryIoc.Scope.TryGetOrAddWithoutClosure(int id, DryIoc.IResolverContext resolveContext, FastExpressionCompiler.LightExpression.Expression expr, bool useFec, System.Func<DryIoc.IResolverContext, FastExpressionCompiler.LightExpression.Expression, bool, object> createValue, int disposalOrder) Line 12109 C#
DryIoc.dll!DryIoc.Interpreter.TryInterpretMethodCall(DryIoc.IResolverContext r, FastExpressionCompiler.LightExpression.Expression expr, object paramExprs, object paramValues, DryIoc.Interpreter.ParentLambdaArgs parentArgs, bool useFec, ref object result) Line 3622 C#
DryIoc.dll!DryIoc.Interpreter.TryInterpret(DryIoc.IResolverContext r, FastExpressionCompiler.LightExpression.Expression expr, object paramExprs, object paramValues, DryIoc.Interpreter.ParentLambdaArgs parentArgs, bool useFec, out object result) Line 3023 C#
DryIoc.dll!DryIoc.Interpreter.TryInterpretAndUnwrapContainerException(DryIoc.IResolverContext r, FastExpressionCompiler.LightExpression.Expression expr, bool useFec, out object result) Line 2864 C#
DryIoc.dll!DryIoc.Container.ResolveAndCache(int serviceTypeHash, System.Type serviceType, DryIoc.IfUnresolved ifUnresolved) Line 409 C#
DryIoc.dll!DryIoc.Container.DryIoc.IResolver.Resolve(System.Type serviceType, DryIoc.IfUnresolved ifUnresolved) Line 356 C#
DryIoc.dll!DryIoc.Resolver.Resolve(DryIoc.IResolver resolver, System.Type serviceType) Line 8008 C#
I was trying to figure out what’s causing this so I started reading DryIoc code and one method in particular looks suspicious:

The deadlock happens inside the WaitForItemIsSet method and I don’t understand how it’s ever going to get set. Is this maybe a bug?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (11 by maintainers)
Commits related to this issue
- added the failing test for the #391 — committed to dadhi/DryIoc by dadhi 3 years ago
- improving the message for #391 — committed to dadhi/DryIoc by dadhi 3 years ago
- improving the message for #391 — committed to dadhi/DryIoc by dadhi 3 years ago
- enable changing the wait timeout for #391 — committed to dadhi/DryIoc by dadhi 3 years ago
- added the failing test for the #391 — committed to yallie/DryIoc by dadhi 3 years ago
- attempt to fix #391 by introducing the fixed waiting timeout; TODO: make the timeout configurable — committed to yallie/DryIoc by dadhi 3 years ago
- improving the message for #391 — committed to yallie/DryIoc by dadhi 3 years ago
- improving the message for #391 — committed to yallie/DryIoc by dadhi 3 years ago
- enable changing the wait timeout for #391 — committed to yallie/DryIoc by dadhi 3 years ago
@Artemigos I will close it for now but will link the issue from the discussion to not forget.
Found it:
It deadlocks on the second resolve. The dependency structure is also important.
Yup, the deadlock is solved for me - providing all the dependencies got rid of the problem.