EXC_BAD_ACCESS to Typhoon Singleton Reference

Question

I'm using the Typhoon Framework to integrate all of my core components. I'm working on my data layer (using FMDB instead of Core Data). I have a LocalDataStore class that handles the reading and writing of data to SQLite. This is a singleton class that has an initialization method that sets up the database. Then I have a PlayerDAO that references it.

When I launch the app, the LocalDataStore gets created and the initialization method gets called. It then goes to create the DAO class, and when it tries to access the LocalDataStore, I'm receiving an EXC_BAD_ACCESS error.

Turning on "Enable Zombie Objects" in the launch scheme, I get an additional error: -[myapp.SQLiteLocalStore retain]: message sent to deallocated instance 0x1740ab5e0

Here's how I set things up in my Typhoon Assembly:

dynamic func config() -> TyphoonDefinition {
    return TyphoonDefinition.configDefinitionWithName("MyApp.plist")
}

dynamic func localStore() -> AnyObject {
    return TyphoonDefinition.withClass(SQLiteLocalStore.self, configuration: {
        (definition) in

        definition.injectProperty("databaseName", with: TyphoonConfig("sqlite.filename"))

        definition.performAfterInjections("initDatabase")
        definition.scope = .Singleton
    })
}

dynamic func playerDAO() -> AnyObject {     
    return TyphoonDefinition.withClass(SQLitePlayerDAO.self, configuration: {
        (definition) in

        definition.injectProperty("localStore", with: self.localStore())
    })
}

Looking at the breakpoint when the error occurs, it's happening on this line in TyphoonComponentFactory:

- (id)newOrScopeCachedInstanceForDefinition:(TyphoonDefinition *)definition args:(TyphoonRuntimeArguments *)args {
   ...
   instance = [pool objectForKey:poolKey];   // line 431
   ...
}

poolKey = @"localStore"

The debugger says it's currently initializing playerDAO. The pool has only 1 key of "localStore" and the value is _NSZombie_myApp.SQLiteLocalStore

Any idea on what could be going wrong?

Answer 1

Well, changing definition.scope = .Singleton to definition.scope = .LazySingleton fixed it... and in my case, is probably a better approach anyway.

I'm still curious if I was doing something wrong to cause the memory error with the plain Singleton.