The long wall clock time and the short CPU time suggests that you spent most of the time blocking. Your crash report isn’t symbolicated so it’s hard to say exactly what’s going on. However, I was able to symbolicate the OS symbols at the top of your main thread:
0 libsystem_kernel.dylib … __ulock_wait + 8
1 libsystem_platform.dylib … _os_unfair_lock_lock_slow + 196 …
2 libobjc.A.dylib … objc_sync_enter + 36 …
3 SDK … 0x1114ec000 + 306572
This suggests that your code (frame 3) is using a @synchronized and it can’t get that lock because it’s being held by some other thread. For example, this code creates a similar backtrace:
@interface Test : NSObject
@end
@implementation Test
- (void)test {
[self performSelectorInBackground:@selector(_backgroundAction) withObject:nil];
[NSThread sleepForTimeInterval:0.1];
@synchronized (self) {
NSLog(@"Hello Cruel World");
}
}
- (void)_backgroundAction {
@synchronized (self) {
pause();
}
}
@end
As to what’s causing this, it’s hard to say without a properly symbolicated log. To start, you need to work out the identity of frames 9 through 3 on your main thread. However, there are a lot of other threads in this process, many of which are blocked in hard to understand ways.
Do you know if this app is using a third-party crash reporter? Or is your SDK a third-party crash reporter? It’s not uncommon for third-party crash reporters to cause weird hangs like this because… well… frankly… it’s not possible to create a reliable third-party crash reporter on iOS. See Implementing Your Own Crash Reporter for more background on this.
Regardless, the next step here is to symbolicate your frames in this crash report. See Adding Identifiable Symbol Names to a Crash Report for advice on that front.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
