Я пишу метод инициализации для CloudKit. Проблема, с которой я столкнулась, возникает при получении идентификатора пользователя/состояния учетной записи.iOS CloudKit crash на блоке завершения для -fetchUserRecordIDWithCompletionHandler:
Я звоню [[CKContainer defaultContainer] fetchUserRecordIDWithCompletionHandler:]
.
Немного позже, и отладчик указывает мне на поток «Queue: com.apple.cloudkit.operation.callback (serial) queue».
Этот метод является единственным методом, связанным с CloudKit, с обратным вызовом, который должен выполняться.
Вот сам метод:
[[CKContainer defaultContainer] fetchUserRecordIDWithCompletionHandler:^(CKRecordID *recordID, NSError *error) {
NSLog(@"CLOUDKIT Fetching User Record ID");
if (error) {
NSLog(@"[%@] Error loading CloudKit user: %@", self.class, error);
}
if (recordID) {
NSLog(@"CLOUDKIT Found User Record ID: %@", recordID.recordName);
// If there is a record ID we check for account status
[[CKContainer defaultContainer] accountStatusWithCompletionHandler:^(CKAccountStatus accountStatus, NSError *error) {
NSLog(@"CLOUDKIT Finding Account Status");
if (error) {
NSLog(@"[%@] Error checking CloudKit availability: %@", self.class, error);
}
if (accountStatus == CKAccountStatusAvailable) {
NSLog(@"CLOUDKIT Account Available, beginning initial sync");
// We have an available account. If we have a new user do a complete sync
NSString *userRecordID = [[NSUserDefaults standardUserDefaults] stringForKey:CLOUD_KIT_CURRENT_USER_ID_USER_DEFAULT];
if (userRecordID == nil || ![recordID.recordName isEqualToString:userRecordID]){
[self syncAllData];
} else {
// If there haven't been any updates, just sync as usual
[self syncChanges];
}
// Subscribe to zone updates
[self subscribeToDefaultZoneUpdates];
} else {
NSLog(@"[%@] Cloudkit account is either unavailable or restricted", self.class);
}
}];
} else {
NSLog(@"[%@] CloudKit user Record ID not found", self.class);
}
}];
Есть NSLogs до и после этого, что в настоящее время выполняются, но NSLog на самом верху («CLOUDKIT Извлечение пользователя Record ID») никогда не будет выполнена.
Когда он падает, журнал не дает мне никакой информации. Вот очередь нити из Xcode:
Вот что на самом деле выкладывает в отладочный навигатора.
libsystem_kernel.dylib`__pthread_kill:
0x332f7df4: mov r12, #0x148
0x332f7df8: svc #0x80
0x332f7dfc: blo 0x332f7e14 ; __pthread_kill + 32
0x332f7e00: ldr r12, [pc, #4] ; __pthread_kill + 24
0x332f7e04: ldr r12, [pc, r12]
0x332f7e08: b 0x332f7e10 ; __pthread_kill + 28
0x332f7e0c: rsbeq lr, r6, #0x80000001
0x332f7e10: bx r12
0x332f7e14: bx lr
В частности, это нарушение в 0x332f7dfc: blo 0x332f7e14 ; __pthread_kill + 32
Вы на самом деле рушились или просто ломались? Смысл, если вы нажмете «продолжить» в отладчике, продолжаете ли вы? Вы пытались ударить его, пока что-то не произойдет? У вас есть включенная точка останова «все исключения»? Какую конкретную линию вы нарушаете? Иногда API Apple, по какой-то причине, бросает нефатальные исключения, я видел это с помощью AVAudioPlayer. –
Удар по-прежнему не дает мне никакой новой информации. Он просто выплевывает больше сборки, пока не попаду в ловушку. Это не дает мне номер строки. Перерыв в навигаторе отладки. – Jonathan
Дело в том, где он на самом деле нарушение выглядит так: libsystem_kernel.dylib'__pthread_kill: 0x332f7df4: мов r12, # 0x148 0x332f7df8: SVC# 0x80 0x332f7dfc: Бло 0x332f7e14; __pthread_kill + 32 0x332f7e00: ldr r12, [pc, # 4]; __pthread_kill + 24 0x332f7e04: ldr r12, [pc, r12] 0x332f7e08: b 0x332f7e10; __pthread_kill + 28 0x332f7e0c: rsbeq lr, r6, # 0x80000001 0x332f7e10: bx r12 0x332f7e14: bx lr – Jonathan