We encountered a bizarre error in an async context; this PR offers a solution to two problems. (A topic of note here is that the GraphIdentifier is a class. We will come back to this later).

• GraphIdentifier dereference crash, e.g. EXC_BAD_ACCESS: KERN_INVALID_ADDRESS: Attempted to dereference garbage pointer
• Race condition wherein an async call to Lazy.instance could acquire the lock, set the graph identifier, release the lock, then re-acquire the lock and begin resolving. In between the lock release/acquisition of one .instance call, another .instance call could update the GraphIdentifier before the first thread could call resolve and re-acquire the lock. Can results in unexpected behaviour.

Synchronization

Synchronizing a container will emit a child which ensures that any async calls to resolve(…) should happen sequentially and never concurrently (or more precisely, for the logic within).

One line here is quite interesting:

It happens within the sync context, so it should be safe. However, there is one Swinject object that also contains a graph identifier reference. That is Lazy.

A Lazy property can be held by any class. Once that class is dereferenced/deallocated so are its children, in this case the ObjectIdentifier being one of them.

Critically, we have no control over when a Lazy property (and its GraphIdentifier ref) might be released.

deinit {
    container?.lock.sync {
        // THIS AVOIDS THE DEREFERENCE CRASH
        self.graphIdentifier = nil
    }
}

• To further my point, the above line entirely prevents the crash when added to the Lazy type.

Solution

This one fairly simple and results meets expectations for GraphIdentifier behaviour. It should be an Identifiable struct, the performance tradeoffs here are negligible: a smidge costlier to create, but faster to pass by value (requires no ARC calls).

Some debug artifacts…

• Swift ARC concurrency crashes are really hard to debug…so in this case it helps to have an extra pair of eyes and some compiler help
• neat Swift forum thread on @_assemblyVision