我们正在发生一个奇怪的崩溃-现在我确定是什么原因造成的,但是我注意到的一件奇怪的事情是,所有崩溃日志在两个单独的后台线程上都有-applicationDidBecomeActive
Thread 5:
0 libsystem_kernel.dylib 0x00007fffaebac456 semaphore_wait_trap + 10
1 MyApp 0x0000000107389da1 -[OutputManager(TechSmithCloud) reloadCloudDestinations] (OutputManager+TechSmithCloud.m:59)
2 MyApp 0x000000010728c4b4 __44-[AppController applicationDidBecomeActive:]_block_invoke (AppController.m:696)
3 libdispatch.dylib 0x00007fffaea57f5f _dispatch_call_block_and_release + 12
4 libdispatch.dylib 0x00007fffaea4f128 _dispatch_client_callout + 8
5 libdispatch.dylib 0x00007fffaea51099 _dispatch_root_queue_drain + 917
6 libdispatch.dylib 0x00007fffaea50cb7 _dispatch_worker_thread3 + 99
7 libsystem_pthread.dylib 0x00007fffaec9b746 _pthread_wqthread + 1299
8 libsystem_pthread.dylib 0x00007fffaec9b221 start_wqthread + 13
Thread 13:
0 libsystem_kernel.dylib 0x00007fffaebac456 semaphore_wait_trap + 10
1 MyApp 0x0000000107389da1 -[OutputManager(TechSmithCloud) reloadCloudDestinations] (OutputManager+TechSmithCloud.m:59)
2 MyApp 0x000000010728c4b4 __44-[AppController applicationDidBecomeActive:]_block_invoke (AppController.m:696)
3 libdispatch.dylib 0x00007fffaea57f5f _dispatch_call_block_and_release + 12
4 libdispatch.dylib 0x00007fffaea4f128 _dispatch_client_callout + 8
5 libdispatch.dylib 0x00007fffaea51099 _dispatch_root_queue_drain + 917
6 libdispatch.dylib 0x00007fffaea50cb7 _dispatch_worker_thread3 + 99
7 libsystem_pthread.dylib 0x00007fffaec9b746 _pthread_wqthread + 1299
8 libsystem_pthread.dylib 0x00007fffaec9b221 start_wqthread + 13
而且我无法对此进行复制(我在
-applicationDidBecomeActive
中注销了一条语句,并且一次只能注销一次)所以我不确定这是不可能的,还是一个实际的问题
也许是与信号量有关的事情?
这是代码:
- (void)applicationDidBecomeActive:(NSNotification *)aNotification
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^
{
[[OutputManager sharedOutputManager] reloadCloudDestinations];
});
}
编辑:
-reloadCloudDestinations
的代码-(void) reloadCloudDestinations
{
[self setupCloudLibrary];
TSCAccount* account = [TSCCloudServices activeAccount];
if( account.status == TSCAccount_SignedIn )
{
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
__weak __typeof(self) weakSelf = self;
@try
{
AFHTTPSessionManager *test = (AFHTTPSessionManager*)[(TSCAccountHTTPSession*)[self.libraryCore valueForKey:@"sessionManager"] valueForKey:@"httpClient"];
NSLog(@"%@", test);
[self.libraryCore destinationsWithActions:NEVER_TRANSLATE(@"publish,list") completionBlock:^(NSArray *destinations, NSError *error) {
@try
{
if( error == nil )
{
[weakSelf createButtonsForNewDestinationsNotAlreadyPresent:destinations];
}
else
{
NSLog(@"destinationsWithBlock error: %@", error);
}
}
@catch (NSException* exception)
{
NSLog(@"reloadCloudDestinations - destinationWithBlock completion - An exception was thrown %@", exception);
}
@finally
{
dispatch_semaphore_signal(semaphore);
}
}];
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
}
@catch (NSException* exception)
{
NSLog(@"reloadCloudDestinations - An exception was thrown %@", exception);
dispatch_semaphore_signal(semaphore);
}
}
}
最佳答案
回溯具有符号__44-[AppController applicationDidBecomeActive:]_block_invoke
。那不是-applicationDidBecomeActive:
方法本身。它是编译器为-applicationDidBecomeActive:
方法中显示的块生成的函数的名称。
阻止功能出现在后台线程中,因为您正在将其分派到除主队列之外的其他队列中。这不是问题,只是一个解释。
可能会出现多次,可能是因为您的应用程序处于活动状态,已退出活动状态,然后在整个生命周期中再次处于活动状态。每次它变为活动状态时,都会在主线程上调用-applicationDidBecomeActive:
。那将把该块提交到全局并发队列,并假设存在可用的CPU核心和其他系统资源,然后它将在后台线程上执行。
一个悬而未决的问题是,为什么当崩溃发生时这些块仍在运行,而不是在短时间内完成。您没有显示-[OutputManager reloadCloudDestinations]
的代码,因此很难知道。显然,它等待计数为零或更少的信号量。
关于multithreading - -applicationDidBecomeActive`如何在两个单独的后台线程上同时调度?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/41047732/