Crashing when running Unit Tests
Closed this issue · 6 comments
When the Unit Tests suit starts, it will setup an observer on a singleton I got, as part of the application starting:
self.loginStateManagerKVOController = [FBKVOController controllerWithObserver:self];
[self.loginStateManagerKVOController observe:[WHLoginStateManager sharedManager] keyPath:@"userLoggedIn" options:NSKeyValueObservingOptionNew block:^(id *mainViewController, id *loginStateManager, NSDictionary *change) {
// ....
}];
Then I add another observer (this time as part of the Unit Test itself):
self.stateManagerKVOController = [FBKVOController controllerWithObserver:self];
[self.stateManagerKVOController observe:[WHLoginStateManager sharedManager] keyPath:@"accountDetails.firstName" options:NSKeyValueObservingOptionNew block:^(id *loginViewModel,id *stateManager, NSDictionary *change) {
// ...
}];
And the stack trace:
Thread 1Queue : com.apple.main-thread (serial)
#0 0x0000000112db0159 in objc_registerClassPair ()
#1 0x00000001111b76ec in _NSKVONotifyingCreateInfoWithOriginalClass ()
#2 0x00000001111b7654 in _NSKeyValueContainerClassGetNotifyingInfo ()
#3 0x0000000111195ba6 in -[NSKeyValueUnnestedProperty _isaForAutonotifying] ()
#4 0x0000000111195a26 in -[NSKeyValueUnnestedProperty isaForAutonotifying] ()
#5 0x00000001111b70c8 in -[NSObject(NSKeyValueObserverRegistration) _addObserver:forProperty:options:context:] ()
#6 0x00000001111b6d0d in -[NSObject(NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] ()
#7 0x0000000120d75ff8 in -[_FBKVOSharedController observe:info:]
#8 0x0000000120d776ff in -[FBKVOController _observe:info:]
#9 0x0000000120d780ac in -[FBKVOController observe:keyPath:options:block:]
#10 0x0000000120bf05d0 in -[WHLoginViewModel setupObservers]
#11 0x0000000120bf04a6 in -[WHLoginViewModel init]
#12 0x0000000120bf352d in -[WHLoginTesting testShouldReturnErrorForNoInternet]
#13 0x000000011378422c in __invoking___ ()
#14 0x0000000113784082 in -[NSInvocation invoke] ()
#15 0x000000012147e1df in -[XCTestCase invokeTest] ()
#16 0x000000012147e3e0 in -[XCTestCase performTest:] ()
#17 0x0000000121487ce5 in -[XCTest run] ()
#18 0x000000012147d14b in -[XCTestSuite performTest:] ()
#19 0x0000000121487ce5 in -[XCTest run] ()
#20 0x000000012147d14b in -[XCTestSuite performTest:] ()
#21 0x0000000121487ce5 in -[XCTest run] ()
#22 0x000000012147d14b in -[XCTestSuite performTest:] ()
#23 0x0000000121487ce5 in -[XCTest run] ()
#24 0x000000012147a20c in __25-[XCTestDriver _runSuite]_block_invoke ()
#25 0x0000000121484f9d in -[XCTestObservationCenter _observeTestExecutionForBlock:] ()
#26 0x000000012147a140 in -[XCTestDriver _runSuite] ()
#27 0x000000012147ab6d in -[XCTestDriver _checkForTestManager] ()
#28 0x000000012148abd0 in +[XCTestProbe runTests:] ()
#29 0x00000001111eea75 in __NSFireDelayedPerform ()
#30 0x00000001137f44e4 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#31 0x00000001137f40a5 in __CFRunLoopDoTimer ()
#32 0x00000001137b73dd in __CFRunLoopRun ()
#33 0x00000001137b6a06 in CFRunLoopRunSpecific ()
#34 0x0000000114d349f0 in GSEventRunModal ()
#35 0x00000001118cf550 in UIApplicationMain ()
#36 0x000000010ff0bd73 in main
#37 0x00000001146e8145 in start ()
And the crash is here:
[object addObserver:self forKeyPath:info->_keyPath options:info->_options context:(void *)info];
With:
Thread 1: EXC_BAD_ACCESS (code=1, address=0x20)
If I stop the initial app setup (like commenting the observing part [WHLoginStateManager sharedManager]
), or overriding the bootstrap since it's starting because of the Unit Tests, there is no crash.
Is it possible to create a standalone reduction? e.g. does observing any singleton in a unit test environment reproduce, or is there something particular to WHLoginStateManager?
The singleton is as simple as:
+ (instancetype)sharedManager
{
static WHLoginStateManager *sharedManager = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedManager = [[self alloc] init];
});
return sharedManager;
}
There is no override of init
.
Hm, it looks like this is crashing inside the Objective-C runtime. That might indicate corruption from somewhere else, but I'm not sure how that could happen.
Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.
Same issue here, I'm using 1.0.1.
Not even observe singleton but very common object class.
Thank you for your patience. We're going to close out this issue. If you're still experiencing the problem described, please reopen the issue - thanks!