I'm getting this inconsistent, hard to reproduce crash in RestKit. The crash occurs on NSManagedObjectContext::save(), inside RKManagedObjectRequestOperation::saveContextToPersistentStore:failedContext:error (here's the exact line of code).
This crash happened to over a dozen different users in our production environment but I've personally been unable to reproduce it. I have no clue as to what might be causing this crash. My only clue is _forceRegisterLostFault which may suggest faulted/deleted objects are involved.
Background: RKManagedObjectRequestOperation::saveContextToPersistentStore:failedContext:error is invoked every time RestKit mapping is completed following a network request.
Has anyone encountered this particular EXC_BREAKPOINT in CoreData before?
Any suggestions on how to tackle this?
Stack trace:
Crashed: NSManagedObjectContext 0x1741cf5a0
0 CoreData 0x18add7c7c -[NSManagedObjectContext(_NSInternalAdditions) _forceRegisterLostFault:] + 160
1 CoreData 0x18ad5c8b0 -[NSManagedObjectContext(_NSInternalAdditions) _validateObjects:forOperation:error:exhaustive:forSave:] + 2884
2 CoreData 0x18ad5bcf8 -[NSManagedObjectContext(_NSInternalAdditions) _validateChangesForSave:] + 364
3 CoreData 0x18ad5b94c -[NSManagedObjectContext(_NSInternalChangeProcessing) _prepareForPushChanges:] + 196
4 CoreData 0x18ad51ec4 -[NSManagedObjectContext save:] + 544
5 RestKit 0x1013214b8 __84-[RKManagedObjectRequestOperation saveContextToPersistentStore:failedContext:error:]_block_invoke (RKManagedObjectRequestOperation.m:800)
6 CoreData 0x18add5b70 developerSubmittedBlockToNSManagedObjectContextPerform + 152
7 libdispatch.dylib 0x1878e91c0 _dispatch_client_callout + 16
8 libdispatch.dylib 0x1878f6860 _dispatch_barrier_sync_f_invoke + 84
9 CoreData 0x18add5a80 -[NSManagedObjectContext performBlockAndWait:] + 308
10 RestKit 0x1013212b8 -[RKManagedObjectRequestOperation saveContextToPersistentStore:failedContext:error:] (RKManagedObjectRequestOperation.m:808)
11 RestKit 0x1013216d0 -[RKManagedObjectRequestOperation saveContext:error:] (RKManagedObjectRequestOperation.m:831)
12 RestKit 0x101321f54 -[RKManagedObjectRequestOperation saveContext:] (RKManagedObjectRequestOperation.m:874)
13 RestKit 0x10131f654 __79-[RKManagedObjectRequestOperation performMappingOnResponseWithCompletionBlock:]_block_invoke.350 (RKManagedObjectRequestOperation.m:660)
14 RestKit 0x1013534a0 -[RKResponseMapperOperation willFinish] (RKResponseMapperOperation.m:323)
15 RestKit 0x101353ac4 -[RKResponseMapperOperation main] (RKResponseMapperOperation.m:411)
16 Foundation 0x1894578c4 -[__NSOperationInternal _start:] + 620
17 Foundation 0x189524b00 __NSOQSchedule_f + 228
18 libdispatch.dylib 0x1878e91c0 _dispatch_client_callout + 16
19 libdispatch.dylib 0x1878f7444 _dispatch_queue_serial_drain + 928
20 libdispatch.dylib 0x1878ec9a8 _dispatch_queue_invoke + 652
21 libdispatch.dylib 0x1878f938c _dispatch_root_queue_drain + 572
22 libdispatch.dylib 0x1878f90ec _dispatch_worker_thread3 + 124
23 libsystem_pthread.dylib 0x187af22b8 _pthread_wqthread + 1288
24 libsystem_pthread.dylib 0x187af1da4 start_wqthread + 4
There are a few different causes I've seen for this error.
Accessing Managed Objects and/or Contexts on the wrong thread. Use Core Data Concurrency Debugging to validate that you're always using the right thread, with the -com.apple.CoreData.ConcurrencyDebug 1 argument.
Corrupted Sqlite file - does your app include an out-of-box Core Data store? Make sure all the metadata in it is correct.
Overriding the default accessors in your Core Data Managed Objects. Be careful if you have objects with primitive (int or float instead of NSNumber) properties.
Related
My application crashed again, this time exporting the device crash log as follows (mind articles 11 and 12):
I tried to symbolic it, but I didn't know how to get the dSYM files from afnetworking from the project.
Thread 8 name: Dispatch queue: NSOperationQueue 0x2803df960 (QOS: UNSPECIFIED)
Thread 8 Crashed:
0 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
1 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
2 libsystem_malloc.dylib 0x0000000197ccc040 nanov2_allocate$VARIANT$armv81 + 140
3 libsystem_malloc.dylib 0x0000000197ccbf64 nanov2_malloc$VARIANT$armv81 + 60
4 libsystem_malloc.dylib 0x0000000197cd99a0 malloc_zone_malloc + 156
5 CoreFoundation 0x000000019808e160 _CFRuntimeCreateInstance + 324
6 CoreFoundation 0x000000019802b970 __CFArrayInit + 224
7 Foundation 0x0000000198b75470 NSKVOCopyPendingNotificationStack + 152
8 Foundation 0x0000000198b720f8 NSKeyValueWillChangeWithPerThreadPendingNotifications.llvm.16432713543580414412 + 364
9 Foundation 0x0000000198ae8ad4 -[NSProgress _setValueForKeys:settingBlock:] + 272
10 Foundation 0x0000000198aeb9dc -[NSProgress setCompletedUnitCount:] + 132
11 AFNetworking 0x00000001051c965c 0x10519c000 + 185948
12 AFNetworking 0x00000001051d1a18 0x10519c000 + 219672
13 CFNetwork 0x0000000198898b94 __67-[NSURLSession delegate_dataTask:didReceiveData:completionHandler:]_block_invoke.303 + 36
14 Foundation 0x0000000198b8c8bc __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
15 Foundation 0x0000000198a94ab8 -[NSBlockOperation main] + 72
16 Foundation 0x0000000198a93f8c -[__NSOperationInternal _start:] + 740
17 Foundation 0x0000000198b8e790 __NSOQSchedule_f + 272
18 libdispatch.dylib 0x0000000197b356c8 _dispatch_call_block_and_release + 24
19 libdispatch.dylib 0x0000000197b36484 _dispatch_client_callout + 16
20 libdispatch.dylib 0x0000000197b0ce04 _dispatch_continuation_pop$VARIANT$armv81 + 404
21 libdispatch.dylib 0x0000000197b0c4e8 _dispatch_async_redirect_invoke + 592
22 libdispatch.dylib 0x0000000197b18aec _dispatch_root_queue_drain + 344
23 libdispatch.dylib 0x0000000197b1934c _dispatch_worker_thread2 + 116
24 libsystem_pthread.dylib 0x0000000197d1917c _pthread_wqthread + 472
25 libsystem_pthread.dylib 0x0000000197d1bcec start_wqthread + 4
If it's not afnetworking fault, can anyone see why? Please help me.
So, your app has crashed pretty deep in Apple's code, and specifically inside libsystem_malloc. While I cannot be certain, my guess is you're looking at an example of heap corruption.
Dynamically allocated memory is shared by your entire process, and everything in it. That means that any code could potentially overwrite and/or otherwise corrupt structures used by other, even unrelated, parts of the system. In this case, it looks like something has messed up the internal book-keeping structures used by malloc. I would guess this happens by overrunning a buffer and writing outside of an allocated piece of memory's bounds.
What I can say with high confidence is that this particular report does not give you enough information to blame AFNetworking. It just happened to be unlucky enough to be running when that corrupt memory was accessed. Even one memory corruption bug can cause a variety of different crashes. Because of that, it's not really possible to reason about the cause of any one particular crash.
The good news is this kind of thing is very common. Bad news is it can be very hard to track down. What I'd recommend trying is to make use of the memory debugging tools that Apple provides. Things like NSZombies (via instruments), guardmalloc, and malloc scribble. Your best bet is to just fix all the memory-related bugs you can find.
I am having the following crash (0.05% crash rate, so I have yet to reproduce it):
0 libdispatch.dylib 0x208b2028 _dispatch_semaphore_signal_slow + 174
! 1 MyProject 0x00253f39 __64-[CRNSURLSessionTaskProxy wrapDataCompletionHandler:forSession:]_block_invoke + 422
2 CFNetwork 0x2120796d __75-[__NSURLSessionLocal taskForClass:request:uploadFile:bodyData:completion:]_block_invoke + 14
3 CFNetwork 0x21216ef7 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 276
4 Foundation 0x2150a52d __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 6
5 Foundation 0x2146beff -[NSBlockOperation main] + 144
6 Foundation 0x2145e2ef -[__NSOperationInternal _start:] + 772
7 Foundation 0x2150c7ed __NSOQSchedule_f + 190
8 libdispatch.dylib 0x208adf97 _dispatch_queue_drain + 1760
9 libdispatch.dylib 0x208a6f2f _dispatch_queue_invoke + 280
10 libdispatch.dylib 0x208af325 _dispatch_root_queue_drain + 398
11 libdispatch.dylib 0x208af193 _dispatch_worker_thread3 + 92
12 libsystem_pthread.dylib 0x20a3ce0d _pthread_wqthread + 1022
13 libsystem_pthread.dylib 0x20a3c9fc start_wqthread + 6
The crashes only appears on iOS9, none whatsoever on iOS8, but this could just be a coincidence. I am also seeing this via Crittercism breadcrumbs:
I am also using Background Fetches which do hit the network layer.
Any idea why this is happing?
This looks to me like a bug with Crittercism. The class CRNSURLSessionTaskProxy is a Crittercism class (see below), so it's crashing in their code, which is corroborated by the errors in the Crittercism breadcrumbs.
The only Google hit (other than this question) for the class name is this one. If you look at the other classes in that dump that start with CR, you will see CRBreadcrumbs and CRCrash.
Also here's a dump of the Crittercism framework in the Hopper disassembler:
Pretty conclusive I would say.
I'm working on an app that's in the app store, which uses FMDB for interacting with its sqlite database. We've received some crash reports with stack traces like this:
Thread : Crashed: NSOperationQueue 0x170239c20 :: NSOperation 0x17024d7d0 (QOS: LEGACY)
0 libobjc.A.dylib 0x000000019701c0b4 objc_retain + 20
1 MyApp 0x00000001002bdff4 FMDBBlockSQLiteCallBackFunction
2 MyApp 0x00000001002bdb1c FMDBBlockSQLiteCallBackFunction
3 MyApp 0x00000001002b66b4 FMDBBlockSQLiteCallBackFunction
4 MyApp 0x00000001002980fc FMDBBlockSQLiteCallBackFunction
5 MyApp 0x000000010029f20c FMDBBlockSQLiteCallBackFunction
6 CFNetwork 0x00000001851475a4 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 300
7 Foundation 0x00000001866bf1c4 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
8 Foundation 0x0000000186610604 -[NSBlockOperation main] + 96
9 Foundation 0x00000001866001cc -[__NSOperationInternal _start:] + 636
10 Foundation 0x00000001866c1f28 __NSOQSchedule_f + 228
11 libdispatch.dylib 0x0000000197655954 _dispatch_client_callout + 16
12 libdispatch.dylib 0x00000001976600a4 _dispatch_queue_drain + 1448
13 libdispatch.dylib 0x0000000197658a5c _dispatch_queue_invoke + 132
14 libdispatch.dylib 0x0000000197662318 _dispatch_root_queue_drain + 720
15 libdispatch.dylib 0x0000000197663c4c _dispatch_worker_thread3 + 108
16 libsystem_pthread.dylib 0x000000019783522c _pthread_wqthread + 816
However, from reading the FMDB code it looks like FMDBBlockSQLiteCallBackFunction is only called as the callback for SQLite functions created using FMDatabase's makeFunctionNamed:maximumArguments:withBlock: method, which we're not using at all.
Any ideas what could be causing crashes like this?
The didFinish makes it look like you may have a race condition on this line:
6 CFNetwork 0x00000001851475a4 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 300
Try to emulate slow hardware to reproduce the end user’s state.
I am experiencing a mysterious Core Data crash via crash reports in my app, that I am having difficulty coming up with a theory for. No reproduction steps, no obvious causes, but it occurs many thousand times. The crash report is pretty vague but it seems to happen when an NSManagedObject is assigned via property to another? Any theories would be appreciated.
*** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0x1dc92160 <x-coredata://6903F7F9-C600-4A29-A538-B3337F1D0BED/Profile/p47854>''
Last Exception Backtrace:
1 CoreFoundation __exceptionPreprocess + 163
2 libobjc.A.dylib objc_exception_throw + 30
3 CoreData _PFFaultHandlerLookupRow + 1477
4 CoreData _PF_FulfillDeferredFault + 203
5 CoreData _PF_ManagedObject_WillChangeValueForKeywithSetMutation + 71
6 CoreData -[NSManagedObject willChangeValueForKey:withSetMutation:usingObjects:] + 84
7 CoreData -[NSManagedObject _includeObject:intoPropertyWithKey:andIndex:] + 690
8 CoreData -[NSManagedObject _maintainInverseRelationship:forProperty:oldDestination:newDestination:] + 444
9 CoreData -[NSManagedObject _didChangeValue:forRelationship:named:withInverse:] + 1290
10 CoreData -[NSManagedObjectContext observeValueForKeyPath:ofObject:change:context:] + 322
11 Foundation NSKeyValueNotifyObserver + 273
12 Foundation NSKeyValueDidChange + 335
13 Foundation -[NSObject didChangeValueForKey:] + 94
14 CoreData -[NSManagedObject didChangeValueForKey:] + 126
15 CoreData -[NSManagedObject _updateFromRefreshSnapshot:includingTransients:] + 614
16 CoreData -[NSManagedObjectContext _copyChildObject:toParentObject:fromChildContext:] + 96
17 CoreData -[NSManagedObjectContext _parentProcessSaveRequest:inContext:error:] + 554
18 CoreData __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke_0 + 565
19 libdispatch.dylib _dispatch_barrier_sync_f_slow_invoke + 81
20 libdispatch.dylib _dispatch_client_callout + 23
21 libdispatch.dylib _dispatch_main_queue_callback_4CF$VARIANT$up + 227
22 CoreFoundation __CFRunLoopRun + 1291
23 CoreFoundation CFRunLoopRunSpecific + 356
24 CoreFoundation CFRunLoopRunInMode + 104
25 GraphicsServices GSEventRunModal + 74
26 UIKit UIApplicationMain + 1120
27 My App main (main.m:18)
28 libdyld.dylib start + 0
“CoreData could not fulfill a fault” usually happens when you delete some object from the persistent store using one context, but in another context this object still exists, it is a fault, and you try to access some property of it.
Don’t forget that an object can be deleted as a result of cascade deletion rule for a relationship.
Here’s the possible timeline:
The object is fetched in context A. By default it is a fault.
The object representing the same data in the store is fetched in context B.
The object is deleted in context B.
Context B is saved resulting in data deleted from the store.
Some property of the object from context A is accessed.
The fault is being fired. Core Data tries to fulfill the fault, but there’s no data in the persistent store anymore.
If an object that was already fetched has been deleted on another thread or in a different ManagedObjectContext, it is possible that you receive an exception when you try to access a property of the deleted object.
This is due to faulting which is described here:
https://developer.apple.com/library/ios/documentation/cocoa/conceptual/CoreData/Articles/cdFaultingUniquing.html
I have some code that wraps an ALAsset object that is retrieved from enumerating the assets in an ALAssetLibrary. I'm getting reports of users encountering crashes with the part of the wrapper object that asks the ALAsset it contains for metadata.
The code that crashes is in this wrapper class and it simply asks for its ALAsset's metadata like so:
[[myAlAsset defaultRepresentation] metadata];
Here is a partial stack trace that is representative of the crashes I'm seeing:
0
CoreFoundation CFDataGetBytePtr + 5
1
PhotoLibraryServices __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
2
PhotoLibraryServices __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
3
CoreData developerSubmittedBlockToNSManagedObjectContextPerform + 88
4
CoreData -[NSManagedObjectContext performBlockAndWait:] + 114
5
PhotoLibraryServices -[PLManagedAsset adjustmentsXMPRepresentation] + 226
6
AssetsLibrary __33-[ALAssetRepresentation metadata]_block_invoke + 24
7
AssetsLibrary __53-[ALAssetRepresentationPrivate _performBlockAndWait:]_block_invoke + 68
8
CoreData developerSubmittedBlockToNSManagedObjectContextPerform + 88
9
libdispatch.dylib _dispatch_client_callout + 22
10
libdispatch.dylib _dispatch_barrier_sync_f_invoke + 26
11
CoreData -[NSManagedObjectContext performBlockAndWait:] + 106
12
AssetsLibrary -[ALAssetsLibrary _performBlockAndWait:] + 134
13
AssetsLibrary -[ALAssetRepresentationPrivate _performBlockAndWait:] + 176
14
AssetsLibrary -[ALAssetRepresentation metadata] + 464
Does anyone have ideas on what may be going on? The AlAssetLibrary that underlies these assets is saved with a static reference, so it should not be getting cleaned up in memory and so I wouldn't expect the ALAsset to have been invalidated. This issue seems to have started specifically with iOS 7 being released.
The crash itself is EXC_BAD_ACCESS with KERN_INVALID_ADDRESS at 0x0.
This may have caused because of buffer overflows. Pls check the link of apple website which shows the buffer overflow crash report same as you have. Hope this may help you.
https://developer.apple.com/library/ios/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#//apple_ref/doc/uid/TP40002577-SW1