如何找出 IOS 设备上导致错误崩溃报告的原因？
How to find out what caused error crash report on IOS device?
在小型应用程序重构后测试应用程序时，我收到了“Crashlytics”崩溃日志。
试图通过将所有下一个调用（从第二次调用开始）发送到私有串行队列来更改模型以避免双重同步方法调用（同时）。我添加了以下代码：
@interface SynchronizationModel ()
@property (nonatomic) dispatch_queue_t synchronizationQueue;
@end
@implementation SynchronizationModel
BOOL isSynchronizationNotCalled = YES;
#pragma mark - Synchronization
+ (dispatch_queue_t)synchronizationQueue {
static dispatch_queue_t queue;
static dispatch_once_t onceToken;
const char *queueID = "com.app.synchronizationModel.queue";
dispatch_once(&onceToken, ^{
queue = dispatch_queue_create(queueID, DISPATCH_QUEUE_SERIAL);
});
return queue;
}
+ (void)sychronizeOfflineObjects {
if (isSynchronizationNotCalled) {
NSLog(@"%d synchronization without a queue, flag notCalled =", isSynchronizationNotCalled);
isSynchronizationNotCalled = NO;
[self synchronizeOfflineObjectsNonAsynchronous];
} else {
NSLog(@"%d synchronization inside of a queue, flag notCalled =", isSynchronizationNotCalled);
isSynchronizationNotCalled = NO;
__weak typeof(self)weakSelf = self;
dispatch_async(self.synchronizationQueue, ^{
__strong typeof(weakSelf)strongSelf = weakSelf;
[strongSelf synchronizeOfflineObjectsNonAsynchronous];
});
}
// [self sychronizeOfflineObjects]; - uncomment for recursive test
isSynchronizationNotCalled = YES;
}
如您所见，使用递归调用对其进行了测试。它确实起作用了。但有机会亲自尝试 运行 设备上的应用程序。
在极少数地方调用此方法。主要在一个明显的控制器中：
- (IBAction)buttonWasTapped:(id)sender {
if(self.buttonImage.layer.animationKeys.count == 0){
[self synchronizationMethod];
}
}
- (void)synchronizationMethod {
NSLog(@"startWorkWithServer - originally here is some code but it works perfect");
[SynchronzationModel sychronizeOfflineObjects];
} else {
[self startAnimation];
[self performSelector:@selector(delayStop) withObject:nil afterDelay:2.0];
if([webConnectionAllowed isEqualToString:@"NotAllowed"]){
[self showAlertWithTitle:nil message:NSLocalizedString(@"Connection is allowed", nil)];
}
}
}
已将应用程序发送给我的团队负责人进行检查。
他在设备上启动了一个应用程序，但有一段时间（猜想它已经工作了一段时间）它被拒绝并显示一条 SIGABRT 错误消息。
Crashlytics 报告returns：
#0. Crashed: com.twitter.crashlytics.ios.exception
0 App 0x18751d CLSProcessRecordAllThreads + 820509
1 App 0x18751d CLSProcessRecordAllThreads + 820509
2 App 0x187415 CLSProcessRecordAllThreads + 820245
3 App 0x17b34f CLSHandler + 770895
4 App 0x185dfb __CLSExceptionRecord_block_invoke + 814587
5 libdispatch.dylib 0x1c942083 _dispatch_client_callout + 22
6 libdispatch.dylib 0x1c94e33b _dispatch_barrier_sync_f_invoke + 50
7 App 0x1857fd CLSExceptionRecord + 813053
8 App 0x185625 CLSExceptionRecordNSException + 812581
9 App 0x18513b CLSTerminateHandler() + 811323
10 libc++abi.dylib 0x1c4f393f std::__terminate(void (*)()) + 78
11 libc++abi.dylib 0x1c4f3443 __cxa_rethrow + 90
12 libobjc.A.dylib 0x1c4ff1bb objc_exception_rethrow + 42
13 CoreFoundation 0x1d1a55a1 CFRunLoopRunSpecific + 596
14 CoreFoundation 0x1d1a5341 CFRunLoopRunInMode + 104
15 GraphicsServices 0x1e97cbfd GSEventRunModal + 156
16 UIKit 0x223b3e27 -[UIApplication _run] + 574
17 UIKit 0x223ae551 UIApplicationMain + 150
18 App 0x148daf main (main.m:14)
19 libdispatch.dylib 0x1c96f50b (Missing)
但至少我没有 dSYM 文件（只有来自 Crashlytics 的 .txt），所以我没有明显的方法来符号化崩溃日志或了解导致问题的原因。打算在我的设备上测试它，但不确定它是否会崩溃。
线程似乎发生了一些事情，但我不确定线索到底是什么。有人可以建议如何找出导致问题的地方。
再补充一点：有几个人在做一个项目（我对它很陌生），我什至不确定上面放置的代码是否打开了错误（但很有可能）或者甚至在我的改变发生之前。我只是添加了一个小方法，第一次正常调用方法并将所有其余调用同时发送到私有串行队列。因为它是递归工作的，而且这是很小的变化，而且只使用一个额外的私有串行队列，这让我很困惑，对于真正的崩溃来说似乎有点太小了（报告中有线程问题）。
如有任何建议，我们将不胜感激。
看来我应该在这里使用正确的修饰符。将 "strong" 添加到同步队列 属性 解决了这个问题。
这 post 有助于找到解决方案。
What property should I use for a Dispatch Queue after ARC?
在 ARC 之前，队列通常被视为非对象类型，因此 "assign" 有很长的路要走。将其留空即可，因为它是非对象类型的默认修饰符。
在引入 ARC 之后，队列将被视为 Objective-c 对象，我们应该对它们使用 "strong"。需要提到的是，"strong" 现在是 Objective-c 对象的默认 属性 属性，仍然不确定为什么它在上面给出的情况下不起作用。
在小型应用程序重构后测试应用程序时，我收到了“Crashlytics”崩溃日志。 试图通过将所有下一个调用（从第二次调用开始）发送到私有串行队列来更改模型以避免双重同步方法调用（同时）。我添加了以下代码：
@interface SynchronizationModel ()
@property (nonatomic) dispatch_queue_t synchronizationQueue;
@end
@implementation SynchronizationModel
BOOL isSynchronizationNotCalled = YES;
#pragma mark - Synchronization
+ (dispatch_queue_t)synchronizationQueue {
static dispatch_queue_t queue;
static dispatch_once_t onceToken;
const char *queueID = "com.app.synchronizationModel.queue";
dispatch_once(&onceToken, ^{
queue = dispatch_queue_create(queueID, DISPATCH_QUEUE_SERIAL);
});
return queue;
}
+ (void)sychronizeOfflineObjects {
if (isSynchronizationNotCalled) {
NSLog(@"%d synchronization without a queue, flag notCalled =", isSynchronizationNotCalled);
isSynchronizationNotCalled = NO;
[self synchronizeOfflineObjectsNonAsynchronous];
} else {
NSLog(@"%d synchronization inside of a queue, flag notCalled =", isSynchronizationNotCalled);
isSynchronizationNotCalled = NO;
__weak typeof(self)weakSelf = self;
dispatch_async(self.synchronizationQueue, ^{
__strong typeof(weakSelf)strongSelf = weakSelf;
[strongSelf synchronizeOfflineObjectsNonAsynchronous];
});
}
// [self sychronizeOfflineObjects]; - uncomment for recursive test
isSynchronizationNotCalled = YES;
}
如您所见，使用递归调用对其进行了测试。它确实起作用了。但有机会亲自尝试 运行 设备上的应用程序。
在极少数地方调用此方法。主要在一个明显的控制器中：
- (IBAction)buttonWasTapped:(id)sender {
if(self.buttonImage.layer.animationKeys.count == 0){
[self synchronizationMethod];
}
}
- (void)synchronizationMethod {
NSLog(@"startWorkWithServer - originally here is some code but it works perfect");
[SynchronzationModel sychronizeOfflineObjects];
} else {
[self startAnimation];
[self performSelector:@selector(delayStop) withObject:nil afterDelay:2.0];
if([webConnectionAllowed isEqualToString:@"NotAllowed"]){
[self showAlertWithTitle:nil message:NSLocalizedString(@"Connection is allowed", nil)];
}
}
}
已将应用程序发送给我的团队负责人进行检查。 他在设备上启动了一个应用程序，但有一段时间（猜想它已经工作了一段时间）它被拒绝并显示一条 SIGABRT 错误消息。
Crashlytics 报告returns：
#0. Crashed: com.twitter.crashlytics.ios.exception
0 App 0x18751d CLSProcessRecordAllThreads + 820509
1 App 0x18751d CLSProcessRecordAllThreads + 820509
2 App 0x187415 CLSProcessRecordAllThreads + 820245
3 App 0x17b34f CLSHandler + 770895
4 App 0x185dfb __CLSExceptionRecord_block_invoke + 814587
5 libdispatch.dylib 0x1c942083 _dispatch_client_callout + 22
6 libdispatch.dylib 0x1c94e33b _dispatch_barrier_sync_f_invoke + 50
7 App 0x1857fd CLSExceptionRecord + 813053
8 App 0x185625 CLSExceptionRecordNSException + 812581
9 App 0x18513b CLSTerminateHandler() + 811323
10 libc++abi.dylib 0x1c4f393f std::__terminate(void (*)()) + 78
11 libc++abi.dylib 0x1c4f3443 __cxa_rethrow + 90
12 libobjc.A.dylib 0x1c4ff1bb objc_exception_rethrow + 42
13 CoreFoundation 0x1d1a55a1 CFRunLoopRunSpecific + 596
14 CoreFoundation 0x1d1a5341 CFRunLoopRunInMode + 104
15 GraphicsServices 0x1e97cbfd GSEventRunModal + 156
16 UIKit 0x223b3e27 -[UIApplication _run] + 574
17 UIKit 0x223ae551 UIApplicationMain + 150
18 App 0x148daf main (main.m:14)
19 libdispatch.dylib 0x1c96f50b (Missing)
但至少我没有 dSYM 文件（只有来自 Crashlytics 的 .txt），所以我没有明显的方法来符号化崩溃日志或了解导致问题的原因。打算在我的设备上测试它，但不确定它是否会崩溃。
线程似乎发生了一些事情，但我不确定线索到底是什么。有人可以建议如何找出导致问题的地方。
再补充一点：有几个人在做一个项目（我对它很陌生），我什至不确定上面放置的代码是否打开了错误（但很有可能）或者甚至在我的改变发生之前。我只是添加了一个小方法，第一次正常调用方法并将所有其余调用同时发送到私有串行队列。因为它是递归工作的，而且这是很小的变化，而且只使用一个额外的私有串行队列，这让我很困惑，对于真正的崩溃来说似乎有点太小了（报告中有线程问题）。
如有任何建议，我们将不胜感激。
看来我应该在这里使用正确的修饰符。将 "strong" 添加到同步队列 属性 解决了这个问题。
这 post 有助于找到解决方案。
What property should I use for a Dispatch Queue after ARC?
在 ARC 之前，队列通常被视为非对象类型，因此 "assign" 有很长的路要走。将其留空即可，因为它是非对象类型的默认修饰符。
在引入 ARC 之后，队列将被视为 Objective-c 对象，我们应该对它们使用 "strong"。需要提到的是，"strong" 现在是 Objective-c 对象的默认 属性 属性，仍然不确定为什么它在上面给出的情况下不起作用。