如何找出是什么导致IOS设备上的错误崩溃报告？

基督复活（复活节快乐）！
在小应用程序重构之后testing应用程序时，我收到了“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; } 

你可以看到使用recursion调用来testing它。 它确实工作。 但有机会尝试亲自在设备上运行应用程序。
这个方法在很less的地方被调用。 主要在一个明显的控制器：

 - (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报告返回：

 #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) 

但是由于至less我没有dSYM文件（只有来自Crashlytics的.txt文件），所以我没有明显的方式来象征崩溃日志或了解是什么导致了这个问题。 要在我的设备上testing它，但不知道它是否会崩溃。

看起来线程发生了一些事情，但是我不确定到底是什么线索。 有人可以build议如何找出造成问题的地方吗？

还有一个补充：有一些人在一个项目上工作（我对它很陌生），我甚至不确定上面的代码是否已经打开了错误（但很可能），或者甚至在我之前发生了变化。 我只是一个小方法，第一次正常调用方法，并发送所有其余的调用同时发生的私人串行队列。 由于它recursion的工作，这是很小的变化，只使用一个额外的私人串行队列，让我困惑，似乎有点太小，真正的崩溃（与报告中的线程问题）。

将不胜感激任何意见。

Answer 1

似乎我应该在这里使用正确的修饰符。 将“强”添加到synchronizationQueue属性解决了这个问题。

这篇文章帮助find解决scheme。

在ARC之后，我应该使用哪个属性来发送调度队列？

在ARC之前，队列被视为一个非对象types，所以“assign”已经很长了。 将它留空将会发挥作用，因为它是非对象types的默认修饰符。

不是在ARC被引入之后，队列被处理为和Objective-c对象一样，我们应该使用“strong”。 值得一提的是，“strong”现在是Objective-c对象的默认属性属性，但仍不清楚为什么在上面给出的情况下没有解决这个问题。