search

AliSoftware / Dip

Simple Swift Dependency container. Use protocols to resolve your dependencies and avoid singletons / sharedInstances!
MIT License
978 stars 75 forks source link

Inconsistent Crash while resolving #227

Open SlashDevSlashGnoll opened 4 years ago

SlashDevSlashGnoll commented 4 years ago

We're seeing a crash in DIP when creating the initial view controller which through it's references winds up trying to resolve a type which results in a crash. This type can be described as such (using made-up names to simplify):

struct Configuration {}

protocol Foo {}

open class SuperClass: Foo {
   var configsByUser: [String: Configuration] = []
}

class SubClass: SuperClass {}

We register SubClass into the dependency container using the type Foo. When we resolve, there seems to be a crash at https://github.com/AliSoftware/Dip/blob/0193aa6bf6151f7ecd88ff26dba6c0525c3eabd6/Sources/AutoInjection.swift#L48

In this specific case it seems to be trying to deal with the property configsByUser above. In the debugger I am able to see the following:

(lldb) po type(of: child.value)
Swift.Dictionary<Swift.String, Configuration>

It seems that the data in the Mirror is neither AutoInjectedPropertyBox nor ImplicitlyUnwrappedOptional. Accessing child.value at all seems to crash as the debugger cannot do anything with it beyond querying the type as far as I can tell. I saw https://bugs.swift.org/browse/SR-2282 that you filed but that doesn't seem to be the same issue.

I'm unsure if this shows a problem with how things are registered or what but I wasn't sure how to chase this further. Any input would be greatly appreciated as this error happens very frequently in the simulator which is destroying our automated testing. We do not think we've seen this at all on an actual device so that could be another data point.

SlashDevSlashGnoll commented 4 years ago

Ah I should also note that we are building with Xcode 11.0 and this issue started during our conversion on the Beta this summer so it seems to be new to this version of the compiler.

ilyapuchka commented 4 years ago

If you don't use autoinjected properties you can disable them until this is resolved (if it still happens with GM?). See https://github.com/AliSoftware/Dip/commit/a8777c067e28f2c6d9e7876ae475a08169a66b64

ilyapuchka commented 4 years ago

@SlashDevSlashGnoll is this still relevant?

SlashDevSlashGnoll commented 4 years ago

Turning off autoinjected properties avoids the problem for us yes. Thanks for the advice. It feels like there's still an issue in there but since we didn't need that feature we could just disable it.

Sorry for not reporting in earlier!