Crash on calling addpersistentstorewithtype - ios

I'm creating a NSPersistentStore with the code below, but it crashes with an error posted farther below.
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
if (persistentStoreCoordinator != nil) {
return persistentStoreCoordinator;
}
// Check if we need to copy initial database store
NSString *storePath = [[self applicationDocumentsDirectory]
stringByAppendingPathComponent: PersistentStoreFilename];
//[self checkPersistentStore:storePath];
NSURL *storeUrl = [NSURL fileURLWithPath:storePath];
// Enable automatic lightweight migration
NSDictionary *options = #{
NSMigratePersistentStoresAutomaticallyOption : #YES,
NSInferMappingModelAutomaticallyOption : #YES
};
NSError *error = nil;
NSDictionary *fileAttributes = [NSDictionary dictionaryWithObject:NSFileProtectionComplete forKey:NSFileProtectionKey];
NSLog(#"fileAttributes ---- %#",fileAttributes);
NSLog(#"before file attributes - storePath ---- %#",storePath);
[[NSFileManager defaultManager] setAttributes:fileAttributes ofItemAtPath:storePath error:&error];
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:[self managedObjectModel]];
NSLog(#"1.persistentStoreCoordinator ---- %#",persistentStoreCoordinator);
NSLog(#"2.applicationDocumentsDirectory ---- %#",[self applicationDocumentsDirectory]);
NSLog(#"3.PersistentStoreFilename ---- %#",PersistentStoreFilename);
NSLog(#"4.storePath ---- %#",storePath);
NSLog(#"4.storeUrl ---- %#",storeUrl);
NSLog(#"5)persistentStoreCoordinator ---- Error loading core data database");
if(![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil URL:storeUrl options:options error:&error]) {
/*Error for store creation should be handled in here*/
// REA - removing current store and replacing with one from bundle
// NSFileManager *fileManager = [NSFileManager defaultManager];
// [fileManager removeItemAtPath:storePath error:nil];
// [self checkPersistentStore:storePath];
NSLog(#"First attempt addPersistentStoreWithType error %#, %#", error, [error userInfo]);
if(![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil URL:storeUrl options:options error:&error]) {
// Even the bundle version isn't loading - something really bad happened and we can't run
NSLog(#"Second attempt addPersistentStoreWithType error %#, %#", error, [error userInfo]);
NSLog(#"6)persistentStoreCoordinator ---- Error loading core data database");
abort();
}
}
return persistentStoreCoordinator;
}
It causes a crash and below are the nslog from the device.
before file attributes - storePath ---- /var/mobile/Containers/Data/Application/AA4EF2AA-1E72-4BC9-A939-732A1BB65E71/Documents/iPhoneCoreData.sqlite
1.persistentStoreCoordinator ----
2.applicationDocumentsDirectory ---- /var/mobile/Containers/Data/Application/AA4EF2AA-1E72-4BC9-A939-732A1BB65E71/Documents
3.PersistentStoreFilename ---- iPhoneCoreData.sqlite
4.storePath ---- /var/mobile/Containers/Data/Application/AA4EF2AA-1E72-4BC9-A939-732A1BB65E71/Documents/iPhoneCoreData.sqlite
4.storeUrl ---- file:///var/mobile/Containers/Data/Application/AA4EF2AA-1E72-4BC9-A939-732A1BB65E71/Documents/iPhoneCoreData.sqlite
Crash Logs:
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.united.UnitedAgentMobileApp exhausted real (wall clock) time allowance of 19.27 seconds | | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 21.220 (user 21.220, system 0.000), 53% CPU", | "Elapsed application CPU time (seconds): 19.319, 48% CPU" | )
Triggered by Thread: 0
Back Trace:
Thread 0 name: Dispatch queue: SQLQueue 0x117dc0080 for UnitediPhoneCoreData.sqlite
Thread 0 Crashed:
0 libcompression.dylib 0x00000001841865d8 zlibDecodeBufferSafe + 40
1 libcompression.dylib 0x000000018418747c zlib_decode_stream_process + 288
2 libcompression.dylib 0x000000018418747c zlib_decode_stream_process + 288
3 CoreData 0x000000018530d92c -[NSSQLiteConnection _decompressedModelWithData:] + 188
4 CoreData 0x000000018530dc5c -[NSSQLiteConnection fetchCachedModel] + 552
5 CoreData 0x00000001852e18b0 __34-[NSSQLCore cachedModelWithError:]_block_invoke + 112
6 CoreData 0x00000001852301d4 -[NSSQLStoreRequestContext executeRequestUsingConnection:] + 248
7 CoreData 0x00000001852b2118 __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke + 84
8 libdispatch.dylib 0x000000018239aa14 _dispatch_client_callout + 16
9 libdispatch.dylib 0x00000001823a3618 _dispatch_queue_barrier_sync_invoke_and_complete + 56
10 CoreData 0x00000001852b2014 -[NSSQLDefaultConnectionManager handleStoreRequest:] + 256
11 CoreData 0x00000001853a2524 -[NSSQLCoreDispatchManager routeStoreRequest:] + 264
12 CoreData 0x00000001852e3fdc -[NSSQLCore dispatchRequest:withRetries:] + 236
13 CoreData 0x00000001852e1738 -[NSSQLCore cachedModelWithError:] + 112
14 CoreData 0x00000001852e297c +[NSSQLCore cachedModelForPersistentStoreWithURL:options:error:] + 688
15 CoreData 0x00000001853363ac -[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:] + 1256
16 CoreData 0x00000001853379c8 -[NSStoreMigrationPolicy+ 1653192 (InternalMethods) _gatherDataAndPerformMigration:] + 772
17 CoreData 0x00000001852bba34 __91-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]_block_invoke + 2896
18 CoreData 0x00000001852c956c gutsOfBlockToNSPersistentStoreCoordinatorPerform + 212
19 libdispatch.dylib 0x000000018239aa14 _dispatch_client_callout + 16
20 libdispatch.dylib 0x00000001823a3618 _dispatch_queue_barrier_sync_invoke_and_complete + 56
21 CoreData 0x00000001852b7944 _perform + 200
22 CoreData 0x00000001851adfa4 -[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:] + 384

So we followed the circuit breaker pattern and followed the below blog post to address the issue.
https://code.tutsplus.com/tutorials/core-data-from-scratch-migrations--cms-21844

Related

UIDocument saveToUrl Delayed Crash

I have a Core Data app that's been running fine for over 4 years. Last week I updated XCode to version 8.2.1 (can't remember what I was running before this, but it had been months since I updated it).
After updating, I'm now getting a crash that I can't track down. There's a delay between doing something in the app, and getting the crash to occur. I have attempted to setup global breakpoints to gain more information, but nothing specific is shown that I can tell.
I don't explicitly spawn any threads myself.
When my app first launches, in the viewDidLoad of my initial viewController I do this:
- (void)viewDidLoad
{
[super viewDidLoad];
NSFileManager* fileManager = [NSFileManager defaultManager];
NSURL* ubiquitousURL = [fileManager URLForUbiquityContainerIdentifier:nil];
NSDictionary* localOptions = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:YES],
NSMigratePersistentStoresAutomaticallyOption,
[NSNumber numberWithBool:YES],
NSInferMappingModelAutomaticallyOption,
nil];
NSURL* localURL = [fileManager URLForDirectory:NSDocumentDirectory
inDomain:NSUserDomainMask
appropriateForURL:nil
create:NO
error:nil];
NSURL* localCoreDataURL = [localURL URLByAppendingPathComponent:#"MyData"];
self.database = [[UIManagedDocument alloc] initWithFileURL:localCoreDataURL];
self.database.persistentStoreOptions = localOptions;
if( [fileManager fileExistsAtPath:[localCoreDataURL path]] )
{
[self.database openWithCompletionHandler: ^(BOOL success) {
//log statement
}];
}
else
{
NSFileCoordinator* coordinator = [[NSFileCoordinator alloc] initWithFilePresenter:nil];
[coordinator coordinateWritingItemAtURL:ubiquitousURL
options:NSFileCoordinatorWritingForDeleting
error:nil
byAccessor:^(NSURL *newURL) {
[[NSFileManager defaultManager] removeItemAtURL:newURL error:nil];
}];
[self.database saveToURL:localCoreDataURL
forSaveOperation:UIDocumentSaveForCreating
completionHandler:^(BOOL success) {
//log statement
}];
}
}
Later in the app, I allow the user to create some data and save it (create a new entity), like this:
NSManagedObjectContext* context = database.managedObjectContext;
NSError* error = nil;
if( ![context save:&error])
{
[AppUtility printNsError:error];
[NSException raise:NSInternalInconsistencyException format:#"An error occurred when saving context: %#",[error localizedDescription]];
}
else
{
if (![[context parentContext] save:&error])
{
NSLog(#"Error Saving Parent Data %#, %#", error, [error userInfo]);
}
}
The app will then run for 15 to 20 seconds, then suddenly crash. There is an error in the log that says
[NSError retain]: message sent to deallocated instance 0x608000443b10
And the output in the debug navigator looks like this:
Thread 1 Queue: com.apple.main-thread
0 __forwarding__
1 _forwarding_prep_0__
2 -[UIDocument saveToURL:forSaveOperation:completionHandler:
3 __55-[UIDocument _saveUnsavedChangesWithCompletionHandler:)_block_invoke_2
4 _dispatch_call_block_and_release
5 _dispatch_client_callout ()
6 _dispatch_main_queue_callback_4CF
7 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
8 __CFRunLoopRun
9 CFRunLoopRunSpecific
10 GSEventRunModal
11 UIApplicationMain
12 main
13 start
14 start
Enqueued from UIDocument File Access (Thread 5)
0 _dispatch_queue_push
1 __55-[UIDocument _saveUnsavedChangesWithCompletionHandler:]_block_invoke
2 _dispatch_call_block_and_release
...
Equeued from com.apple.main-thread (Thread 1)
0 _dispatch_queue_push
1 -[UIDocument _saveUnsavedChangesWithCompletionHandler:]
2 -[UIDocument _autosaveWithCompletionHandler:]
3 +[UIDocument _autosavingTimerDidFireSoContinue:]
4 __NSFireTimer ()
5 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
...
In an attempt to get more information, I enabled Zombie settings, then ran this in XCode:
command script import lldb.macosx.heap
malloc_info --stack-history *memory address*
The output of that didn't seem to point to a specific line in my app:
(lldb) malloc_info --stack-history 0x60820f611fd0
0x000060820f611fd0: malloc( 48) -> 0x60820f611fd0
_NSZombie_NSError stack[0]: addr = 0x60820f611fd0, type=malloc, frames:
[0] 0x000000010ffcb130 libsystem_malloc.dylib`calloc + 30
[1] 0x000000010ea45458 libobjc.A.dylib`class_createInstance + 85
[2] 0x000000010ea4fd55 libobjc.A.dylib`_objc_rootAlloc + 42
[3] 0x000000010de1f19b Foundation`+[NSError errorWithDomain:code:userInfo:] + 37
[4] 0x000000010c1a4a3c CoreData`-[NSPropertyDescription(_NSInternalMethods) _nonPredicateValidateValue:forKey:inObject:error:] + 124
[5] 0x000000010c1a4bc0 CoreData`-[NSRelationshipDescription(_NSInternalMethods) _nonPredicateValidateValue:forKey:inObject:error:] + 80
[6] 0x000000010c1a3b40 CoreData`-[NSManagedObject(_NSInternalMethods) _validateValue:forProperty:andKey:withIndex:error:] + 384
[7] 0x000000010c1a3896 CoreData`-[NSManagedObject(_NSInternalMethods) _validatePropertiesWithError:] + 358
[8] 0x000000010c1a36f7 CoreData`-[NSManagedObject(_NSInternalMethods) _validateForSave:] + 119
[9] 0x000000010c1b3d4c CoreData`-[NSManagedObject validateForInsert:] + 76
[10] 0x000000010c1a2a77 CoreData`-[NSManagedObjectContext(_NSInternalAdditions) _validateObjects:forOperation:error:exhaustive:forSave:] + 1783
[11] 0x000000010c1a2202 CoreData`-[NSManagedObjectContext(_NSInternalAdditions) _validateChangesForSave:] + 146
[12] 0x000000010c1a1f56 CoreData`-[NSManagedObjectContext(_NSInternalChangeProcessing) _prepareForPushChanges:] + 214
[13] 0x000000010c19e972 CoreData`-[NSManagedObjectContext save:] + 562
[14] 0x000000010ce26a9d UIKit`__43-[UIManagedDocument contentsForType:error:]_block_invoke + 30
[15] 0x000000010c1b89a7 CoreData`developerSubmittedBlockToNSManagedObjectContextPerform + 199
[16] 0x000000010c1b885f CoreData`-[NSManagedObjectContext performBlockAndWait:] + 255
[17] 0x000000010ce269f0 UIKit`-[UIManagedDocument contentsForType:error:] + 258
[18] 0x000000010cd9477c UIKit`-[UIDocument saveToURL:forSaveOperation:completionHandler:] + 486
[19] 0x000000010cd962b2 UIKit`__55-[UIDocument _saveUnsavedChangesWithCompletionHandler:]_block_invoke_2 + 156
[20] 0x000000010fd77978 libdispatch.dylib`_dispatch_call_block_and_release + 12
[21] 0x000000010fda10cd libdispatch.dylib`_dispatch_client_callout + 8
[22] 0x000000010fd818a4 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 406
[23] 0x000000010ef9de49 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
[24] 0x000000010ef6337d CoreFoundation`__CFRunLoopRun + 2205
[25] 0x000000010ef62884 CoreFoundation`CFRunLoopRunSpecific + 420
[26] 0x00000001115dfa6f GraphicsServices`GSEventRunModal + 161
[27] 0x000000010c5a1c68 UIKit`UIApplicationMain + 159
[28] 0x000000010bac23bf MyApp`main + 111 at main.m:16:9
[29] 0x000000010fded68d libdyld.dylib`start + 1
[30] 0x0000000110153001 libsystem_pthread.dylib`_thread + 1
Can someone help me diagnose this?

RestKit Core Data NSError dealloc Crash

Trying to get to the bottom of an issue I've been seeing in production builds and FINALLY was able to reproduce it while testing. Using RestKit v0.23.1, when doing an RKManagedObjectRequestOperation using the following code (while plugged into instruments) I get "An Objective-C message was sent to a deallocated 'NSError' object (zombie)" and the app crashes every time there's objects in the response JSON - if the response is something like "objects = ();" there's no crash - so I'm guessing it's somewhere in the RestKit/Core Data mapping or storage?
RKManagedObjectRequestOperation *objectRequestOperation = [_objectManager managedObjectRequestOperationWithRequest:request managedObjectContext:_objectManager.managedObjectStore.mainQueueManagedObjectContext success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) {
DDLogInfo(#"INSIDE SUCCESS BLOCK");
} failure:^(RKObjectRequestOperation *operation, NSError *error) {
DDLogInfo(#"INSIDE ERROR BLOCK");
}];
[objectRequestOperation setWillMapDeserializedResponseBlock:^id(id deserializedResponseBody) {
DDLogInfo(#"Response JSON: %#", deserializedResponseBody);
return deserializedResponseBody;
}];
objectRequestOperation.savesToPersistentStore = YES;
[objectRequestOperation start];
The raw JSON is properly logged inside the setWillMapDeserializedResponseBlock, but the logs inside the success and error block are never reached. Here is the stack trace I get back from crashlytics:
Thread : Crashed: NSOperationQueue Serial Queue
0 libobjc.A.dylib 0x37dd4626 objc_msgSend + 5
1 Foundation 0x2df5802d -[NSError dealloc] + 60
2 libobjc.A.dylib 0x37dd9b6b objc_object::sidetable_release(bool) + 174
3 libobjc.A.dylib 0x37dda0d3 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
4 CoreFoundation 0x2d569501 _CFAutoreleasePoolPop + 16
5 Foundation 0x2df69999 -[__NSOperationInternal _start:] + 1064
6 Foundation 0x2e00d745 __NSOQSchedule_f + 60
7 libdispatch.dylib 0x382b8cbd _dispatch_queue_drain + 488
8 libdispatch.dylib 0x382b5c6f _dispatch_queue_invoke + 42
9 libdispatch.dylib 0x382b95f1 _dispatch_root_queue_drain + 76
10 libdispatch.dylib 0x382b98dd _dispatch_worker_thread2 + 56
11 libsystem_pthread.dylib 0x383e4c17 _pthread_wqthread + 298
This isn't a problem with RestKit. I've seen this problem frequently and it actually looks like the over-release actually happens in Apple's code. The problem happens when you try to save to a Core Data store and it fails. Core Data reports an error as it should, but that error is mishandled.
I had a few scenarios causing the save failures and this is how I fixed them:
The data store is inaccessible because of the Data Protection API.
Either busy wait and let your app fail to launch like this:
while(![[UIApplication sharedApplication] isProtectedDataAvailable]) {
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.5f]];
}
Or disable protection if the data in your store isn't sensitive like this:
[_coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:url
options:#{NSPersistentStoreFileProtectionKey:NSFileProtectionNone}
error:&error];
The important thing is that you don't try to save until you can access the file. If you can re-structure you code to prevent accessing the database when it is inaccessible that is good too. You can use the Data Protection API application delegate methods to trigger that mechanism.
The data store is corrupted - The best thing to do here is to delete the store and start over. Here is a good way to detect a corrupted store using the sqlite library directly.
#import <sqlite3.h>
sqlite3 *dbConnection;
if (sqlite3_open([[url absoluteString] UTF8String], &dbConnection) != SQLITE_OK) {
NSLog(#"[SQLITE] Unable to open database!");
}
sqlite3_stmt *statement = nil;
sqlite3_prepare_v2(dbConnection, "PRAGMA quick_check;", -1, &statement, NULL);
NSString *result = nil;
while (sqlite3_step(statement) == SQLITE_ROW) {
for (int i=0; i<sqlite3_column_count(statement); i++) {
int colType = sqlite3_column_type(statement, i);
if (colType == SQLITE_TEXT) {
const unsigned char *col = sqlite3_column_text(statement, i);
result = [NSString stringWithFormat:#"%s", col];
} else {
NSLog(#"[SQLITE] UNKNOWN DATATYPE");
}
}
}
sqlite3_close(dbConnection);
This runs a sqlite PRAGMA query to perform an integrity check. I use quick_check, but you could also use integrity_check if you are willing to wait the extra time. You can tell things are good using [result isEqualToString:#"ok"]

CoreData could not fulfill a fault with unmodified relationship

I have a entity A, it has a relationship B.
Here is a array fetched from CoreData:
NSPredicate * predicate = [NSPredicate predicateWithFormat:#"isSynchronized = NO"];
NSManagedObjectContext *context = [NSManagedObjectContext MR_contextForCurrentThread];
NSArray * newWordsToSynchronize = [A MR_findAllWithPredicate:predicate inContext:context];
NSMutableArray * newWordsParameters = [NSMutableArray arrayWithCapacity:[asToSynchronize count]];
[newWordsToSynchronize enumerateObjectsUsingBlock:^(A * a, NSUInteger idx, BOOL * stop) {
NSLog(#"============= may have some problem ============");
NSLog(#"[a hasFaultForRelationshipNamed:#\"b\"] = %d", [a hasFaultForRelationshipNamed:#"b"]);
NSLog(#"a.word = %#", a.word);
NSLog(#"a.b.objectID = %#", a.b.objectID);
NSLog(#"a.managedObjectContext = %#", a.managedObjectContext);
NSLog(#"a.b.managedObjectContext = %#", [a.b managedObjectContext]);
NSLog(#"a.b.managedObjectContext = %#", [a.b managedObjectContext]);
NSLog(#"a.managedObjectContext = %#", a.managedObjectContext);
NSDictionary *paramDictionary = #{
#"nbook" : a.b.name,
#"lang" : a.lang,
...
};
[newWordsParameters addObject:paramDictionary];
}];
The [a.b managedObjectContext] method may return nil when I call it at second time and then the app goes crash.
Crash log from console:
2014-01-20 14:29:14.561 MyApp[10563:2e07] a.b.objectID = 0x1754e940 <x-coredata://DFC4F956-D5AC-4264-8717-C07090CA9547/B/p1>
2014-01-20 14:29:14.561 MyApp[10563:2e07] a.managedObjectContext = <NSManagedObjectContext: 0x1754bc00>
2014-01-20 14:29:14.561 MyApp[10563:2e07] a.b.managedObjectContext = <NSManagedObjectContext: 0x1754bc00>
2014-01-20 14:29:14.562 MyApp[10563:2e07] a.b.managedObjectContext = (null)
*** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0x1754e940 <x-coredata://DFC4F956-D5AC-4264-8717-C07090CA9547/B/p1>''
*** First throw call stack:
(
0 CoreFoundation 0x037495e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x034cc8b6 objc_exception_throw + 44
2 CoreData 0x031a233b _PFFaultHandlerLookupRow + 2715
3 CoreData 0x031a1897 -[NSFaultHandler fulfillFault:withContext:forIndex:] + 39
4 CoreData 0x031a1473 _PF_FulfillDeferredFault + 259
5 CoreData 0x031a12c6 _sharedIMPL_pvfk_core + 70
6 CoreData 0x031e7130 _pvfk_5 + 32
7 MyApp 0x00181b00 __68-[CichangAHTTPEngine synchronizeAsOnCompletion:failure:]_block_invoke + 1760
8 CoreFoundation 0x037435eb __NSArrayEnumerate + 571
9 CoreFoundation 0x03743196 -[NSArray enumerateObjectsWithOptions:usingBlock:] + 102
10 CoreFoundation 0x037430a5 -[NSArray enumerateObjectsUsingBlock:] + 53
11 MyApp 0x0018105b -[CichangAHTTPEngine synchronizeAsOnCompletion:failure:] + 1179
12 MyApp 0x00185d9e __65-[CichangAHTTPEngine downloader:didFinishedDownloadObject:]_block_invoke_3 + 2030
13 libdispatch.dylib 0x040717f8 _dispatch_call_block_and_release + 15
14 libdispatch.dylib 0x040864b0 _dispatch_client_callout + 14
15 libdispatch.dylib 0x04074eeb _dispatch_root_queue_drain + 287
16 libdispatch.dylib 0x04075137 _dispatch_worker_thread2 + 39
17 libsystem_pthread.dylib 0x04412dab _pthread_wqthread + 336
18 libsystem_pthread.dylib 0x04416cce start_wqthread + 30
)
libc++abi.dylib: terminating with uncaught exception of type _NSCoreDataException
I found that B will be deallocated after first [a.b managedObjectContext] calling.
I think it was mainly caused by Core Data 1550 error (If I do not call [a.b managedObjectContext], Core Data will reports "The operation couldn’t be completed. (Cocoa error 1550.)"). But what may cause 1550 error and how to fix it?
1550 error report:
Error Domain=NSCocoaErrorDomain Code=1550 "The operation couldn’t be completed. (Cocoa error 1550.)" UserInfo=0x167269c0 {NSLocalizedDescription=The operation couldn’t be completed. (Cocoa error 1550.), Dangling reference to an invalid object.=null, NSValidationErrorObject=<A: 0x16bab420> (entity: A; id: 0x16baae50 <x-coredata://A85EE9AB-97C1-43C1-B92E-A6C906F0C1A8/A/p168> ; data: {
date = "2014-01-21 02:32:00 +0000";
expect = "2014-01-21 02:31:59 +0000";
isSynchronized = 1;
lang = en;
last = "2014-01-21 02:01:59 +0000";
level = 1;
b = "0x16bab460 <x-coredata://A85EE9AB-97C1-43C1-B92E-A6C906F0C1A8/B/p1>";
status = "-1";
studycount = 0;
trans = "v. \U6d4b\U91cf\Uff0c\U6743\U8861 ";
word = measure;
}), NSAffectedObjectsErrorKey=(
"<B: 0x16babd70> (entity: B; id: 0x16bab460 <x-coredata://A85EE9AB-97C1-43C1-B92E-A6C906F0C1A8/B/p1> ; data: <fault>)"
), NSValidationErrorKey=newWordBook, NSValidationErrorValue=<B: 0x16babd70> (entity: B; id: 0x16bab460 <x-coredata://A85EE9AB-97C1-43C1-B92E-A6C906F0C1A8/B/p1> ; data: <fault>), NSValidationErrorShouldAttemptRecoveryKey=true}
If the 1550 error happened, "CoreData could not fulfill a fault" crash will more easer to cause.
“Core Data could not fulfill fault” really means that there was a deletion. There was data in the persistent store. Then managed object representing this data was created. The object was a fault. Then the data in the store was deleted. Then some property of an object was accessed and Core Data tried to fulfill the fault, but couldn’t.
If you’re not doing explicit deletions, then also make sure that implicit deletions are not happening. Deletion behind the scenes could happen when one of your relationships was configured with the cascade deletion rule.
In your example this could happen if the relationship from A to B was configured with cascade rule, and object A was deleted.

GNAudioSourceMic startRecording hangs forever

I'm trying to capture music from an iPhone 4s microphone, using the Gracenote API.
When running on the device, the application gets closed by the OS with failed to launch in time when calling startRecordingon an instance ofGNAudioSourceMic. Find the log below. I copy & pasted most of the code from the GN example app, which is working fine.
There are no issues running it through the simulator.
- (void)mk_initialize
{
AudioSessionInitialize (
NULL,
NULL,
interruptionListenerCallback,
(__bridge void *)(self)
);
#try {
_config = [GNConfig init:GN_CLIENT_ID];
}
#catch (NSException * e) {
NSLog(#"clientId issue");
return;
}
[self.config setProperty: #"debugEnabled"
value: #"1"];
_recognizeFromStream = [GNRecognizeStream gNRecognizeStream:self.config];
_audioConfig = [GNAudioConfig gNAudioConfigWithSampleRate:44100
bytesPerSample:2
numChannels:1];
_audioSourceMicObj = [GNAudioSourceMic gNAudioSourceMic:self.audioConfig];
self.audioSourceMicObj.delegate = self;
NSError *error = nil;
[RecognizeStreamOperation recognizeStreamOperation:self.config];
error = [self.recognizeFromStream startRecognizeSession:op
audioConfig:self.audioConfig];
if (error) {
NSLog(#"ERROR: %#",[error localizedDescription]);
}
[self.audioSourceMicObj startRecording]; // hanging call
[self performSelectorInBackground:#selector(setUpRecognizePCMSession)
withObject:nil];
}
Device Log:
OS Version: iOS 6.1.3 (10B329)
Report Version: 104
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread: 0
Application Specific Information:
XXXXXXX failed to launch in time
Elapsed total CPU time (seconds): 3.080 (user 3.080, system 0.000), 15% CPU
Elapsed application CPU time (seconds): 0.527, 3% CPU
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x397ab0fc __psynch_mutexwait + 24
1 libsystem_c.dylib 0x396f4124 pthread_mutex_lock + 388
2 AudioToolbox 0x30fd54e8 CAMutex::Lock() + 32
3 AudioToolbox 0x3102645c AUConverterBase::Reset(unsigned long, unsigned long) + 48
4 AudioToolbox 0x310df602 AUGenericOutput::Start() + 26
5 AudioToolbox 0x310d1126 AURemoteIO::Start() + 942
6 AudioToolbox 0x31100776 AUMethodStart(void*) + 118
.
.
.
Is another application on your device using the microphone when you try to launch your app? You should make sure to set the audio session category to one that supports recording, and also activate the audio session prior to calling start on the GnAudioSourceMic instance. For example:
NSError *error = nil;
[[AVAudioSession sharedInstance] setCategory:AVAudioSessionCategoryPlayAndRecord error:&error];
if (error) {
NSLog(#"Error setting audio session category: %d, %#", [error code], [error description]);
}
[[AVAudioSession sharedInstance] setActive:YES error:&error];
if (error) {
NSLog(#"Error activating audio session category: %d, %#", [error code], [error description]);
}

Air Printing crash on ipad

I am having a trouble with printing on ipad. My code prints the pdf file perfectly for the first time; but when I print my pdf file for the second time the app freezes and then crashes.
Below is my code:
NSData *myPdfData = [NSData dataWithContentsOfFile:pdfPath];
UIPrintInteractionController *controller = [UIPrintInteractionController sharedPrintController];
if (controller && [UIPrintInteractionController canPrintData:myPdfData]){
controller.delegate = delegate;
UIPrintInfo *printInfo = [UIPrintInfo printInfo];
printInfo.outputType = UIPrintInfoOutputGeneral;
printInfo.jobName = [pdfPath lastPathComponent];
printInfo.duplex = UIPrintInfoDuplexLongEdge;
controller.printInfo = printInfo;
controller.showsPageRange = YES;
controller.printingItem = myPdfData;
// We need a completion handler block for printing.
UIPrintInteractionCompletionHandler completionHandler = ^(UIPrintInteractionController *printController, BOOL completed, NSError *error) {
if(completed && error){
NSLog(#"FAILED! due to error in domain %# with error code %u", error.domain, error.code);
}
};
[controller presentFromRect:[sender frame] inView:senderView animated:YES completionHandler:completionHandler];
}else {
NSLog(#"Couldn't get shared UIPrintInteractionController!");
}
Below is my stack trace from the device:
D
ate/Time: 2011-03-17 20:48:02.523 -0700
OS Version: iPhone OS 4.3 (8F190)
Report Version: 104
Exception Type: 00000020
Exception Codes: 0x8badf00d
Highlighted Thread: 0
Application Specific Information:
Brighton failed to resume in time
Elapsed total CPU time (seconds): 2.310 (user 0.290, system 2.020), 23% CPU
Elapsed application CPU time (seconds): 0.000, 0% CPU
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x30bd2ab0 0x30bc2000 + 68272
1 PrintKit 0x313f2c1a 0x313df000 + 80922
2 PrintKit 0x313ee9ea 0x313df000 + 63978
3 PrintKit 0x313eea90 0x313df000 + 64144
4 PrintKit 0x313eeab4 0x313df000 + 64180
5 PrintKit 0x313e4f96 0x313df000 + 24470
6 PrintKit 0x313e266a 0x313df000 + 13930
7 UIKit 0x335e3656 0x33311000 + 2958934
8 UIKit 0x335e904c 0x33311000 + 2981964
9 UIKit 0x335e8bcc 0x33311000 + 2980812
10 UIKit 0x335e99fc 0x33311000 + 2984444
11 UIKit 0x3343460c 0x33311000 + 1193484
12 Foundation 0x30d306ce 0x30cab000 + 546510
13 CoreFoundation 0x31c43a40 0x31bce000 + 481856
14 CoreFoundation 0x31c45ec4 0x31bce000 + 491204
15 CoreFoundation 0x31c4683e 0x31bce000 + 493630
16 CoreFoundation 0x31bd6ebc 0x31bce000 + 36540
17 CoreFoundation 0x31bd6dc4 0x31bce000 + 36292
18 GraphicsServices 0x32dbf418 0x32dbb000 + 17432
19 GraphicsServices 0x32dbf4c4 0x32dbb000 + 17604
It would be really helpful if anyone could help me figure out the issue.
Thanks in advance!
The clue is in this: "Brighton failed to resume in time."
When printing is finished, control is returned to your app but you take too long to respond. iOS thinks that you've stopped responding to input and kills your app.

Resources