I have a huge issue with the CTCallCenter where the phone crashes if you get a call but never asnwers. Then the music should come back but instead evertyhing just dies.
This is what the code looks like:
_callCenter = [[CTCallCenter alloc] init];
_callCenter.callEventHandler = ^(CTCall* call){
if (call.callState == CTCallStateDialing || call.callState==CTCallStateIncoming) {
_shouldResumeSongIfConnectionIsAlive=NO;
if([[TFAudioPlayer sharedAudioPlayer] status]==TFAudioPlayerStatusPlaying){
[[TFAudioPlayer sharedAudioPlayer] pause];
isAppWasPlaying=YES;
}else isAppWasPlaying=NO;
}else if(call.callState==CTCallStateDisconnected){
if(isAppWasPlaying){
[[TFAudioPlayer sharedAudioPlayer] playForcedFromWhereItStopped];
_shouldResumeSongIfConnectionIsAlive=YES;
}
}
};
I cannot find any way to handle the case where the user doesnt pick up their phone. The CTCallCenter only has Incoming, Disconnect, Connect and Dialing from what I could see.
Does anyone have a clue?
Edit:
This issue only appears when I run the app on the phone when its NOT connected and debugging. The app dies directly when the other person hangs up (missed call).
Stacktrace:
Date/Time: 2012-11-19 14:20:47.470 +0100
OS Version: iPhone OS 5.1 (9B179)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 10
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x356bb004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x356bb1fa mach_msg + 50
2 CoreFoundation 0x372203ec __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x3721f0ea __CFRunLoopRun + 818
4 CoreFoundation 0x371a249e CFRunLoopRunSpecific + 294
5 CoreFoundation 0x371a2366 CFRunLoopRunInMode + 98
6 GraphicsServices 0x320af432 GSEventRunModal + 130
7 UIKit 0x33926e76 UIApplicationMain + 1074
8 My App 0x0001e63c 0x1a000 + 17980
9 My App 0x0001c268 0x1a000 + 8808
Also! If I run the app with DEPLOY POSTPROCESSING = YES it doesnt crash. I dont get it
Related
We have a react-native app that we develop as a standalone app and then we have a pod that exports the app with a native entry point. Part of our app uses react-native-awesome-card-io which works fine when we run the the app as a standalone piece (metro bundler). We use cocoa pods to manage the dependencies that react-native link usually does for us. We were using react-native: 57.8 but had to upgrade to 59.0 in order to be able to integrate our plugin into android apps without having to add filtering for 32/64 bit. Anyways we have an example app that just has a button and when the button is pressed, the action takes the view controller we created and presentModalViewController is triggered. The issue came up after we upgraded react-native, when we call the scanCard function on press in our react-native js, The following error comes up
It worked fine previously and it works if we run the app as a standalone react-native app but when we integrate it, the issue comes up. Here is how we instantiate the react-native plugin.
NOTE: it fails for both our objective-c and swift example consumer apps. I haven't found anything online.
How we load our viewcontroller in our sample app
- (IBAction)launchPaciolanSDKAction:(UIButton *)sender {
printf("Launching PaciolanSDK ...");
UIViewController *viewController = nil;
viewController = [[PaciolanSDKViewController alloc] initWithString::""];
[self presentModalViewController:viewController animated:YES];
}
Error:
Exception 'Please add -ObjC to 'Other Linker Flags' in your project settings. (+[NSObject testForObjCLinkerFlag]: unrecognized selector sent to class 0x1dbbd7eb0)' was thrown while invoking scanCard on target CardIOModule with params (
{
hideCardIOLogo = 1;
requireCardholderName = 1;
suppressManualEntry = 1;
usePaypalActionbarIcon = 0;
},
3544,
3545
)
callstack: (
0 CoreFoundation 0x00000001a1cf5ebc <redacted> + 252
1 libobjc.A.dylib 0x00000001a0ec5a50 objc_exception_throw + 56
2 CoreFoundation 0x00000001a1bfc484 <redacted> + 0
3 RNAwesomeCardIO 0x000000010385bf6c -[CardIOPaymentViewController initWithPaymentDelegate:scanningEnabled:] + 660
4 RNAwesomeCardIO 0x00000001038598bc -[RCTCardIOModule scanCard:resolver:rejecter:] + 236
5 CoreFoundation 0x00000001a1cfd610 <redacted> + 144
6 CoreFoundation 0x00000001a1bdb340 <redacted> + 292
7 CoreFoundation 0x00000001a1bdbf24 <redacted> + 60
8 React 0x0000000103ec3d10 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 2064
9 React 0x0000000103ecfe2c _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 664
10 React 0x0000000103ecf99c _ZZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEiENK3$_0clEv + 144
11 React 0x0000000103ecf900 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 28
12 libdispatch.dylib 0x000000010494f824 _dispatch_call_block_and_release + 24
13 libdispatch.dylib 0x0000000104950dc8 _dispatch_client_callout + 16
14 libdispatch.dylib 0x000000010495ea78 _dispatch_main_queue_callback_4CF + 1360
15 CoreFoundation 0x00000001a1c85ce4 <redacted> + 12
16 CoreFoundation 0x00000001a1c80bac <redacted> + 1964
17 CoreFoundation 0x00000001a1c800e0 CFRunLoopRunSpecific + 436
18 GraphicsServices 0x00000001a3ef9584 GSEventRunModal + 100
19 UIKitCore 0x00000001cefe0c00 UIApplicationMain + 212
20 sample 0x0000000102f0e1fc main + 124
21 libdyld.dylib 0x00000001a173ebb4 <redacted> + 4
)
Check out your parameters and headers that you are sending to api.This error mostly occur when we send wrong parameters.
My app is essentially a collection of cards, each with various messages/information on it. One swipes to go through these cards, generally swiping right. I am currently getting this sig abrt error:
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char * argv[]) {
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
It also prints, this:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[filterPageViewController askForPushNotifications]: unrecognized selector sent to instance 0x7f8b6d0acd80'
*** First throw call stack:
(
0 CoreFoundation 0x000000010fa92d85 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x000000010f506deb objc_exception_throw + 48
2 CoreFoundation 0x000000010fa9bd3d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3 CoreFoundation 0x000000010f9e1cfa ___forwarding___ + 970
4 CoreFoundation 0x000000010f9e18a8 _CF_forwarding_prep_0 + 120
5 Lettuce 0x000000010a2780a6 -[DraggableViewBackground cardSwipedRight:] + 2470
6 Lettuce 0x000000010a2d0ad5 -[DraggableView rightAction] + 453
7 Lettuce 0x000000010a2d02ed -[DraggableView afterSwipeAction] + 77
8 Lettuce 0x000000010a2cfe22 -[DraggableView beingDragged:] + 1922
9 UIKit 0x000000010d9c7b28 _UIGestureRecognizerSendTargetActions + 153
10 UIKit 0x000000010d9c419a _UIGestureRecognizerSendActions + 162
11 UIKit 0x000000010d9c2197 -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:] + 843
12 UIKit 0x000000010d9ca655 ___UIGestureRecognizerUpdate_block_invoke898 + 79
13 UIKit 0x000000010d9ca4f3 _UIGestureRecognizerRemoveObjectsFromArrayAndApplyBlocks + 342
14 UIKit 0x000000010d9b7e75 _UIGestureRecognizerUpdate + 2634
15 UIKit 0x000000010d54448e -[UIWindow _sendGesturesForEvent:] + 1137
16 UIKit 0x000000010d5456c4 -[UIWindow sendEvent:] + 849
17 UIKit 0x000000010d4f0dc6 -[UIApplication sendEvent:] + 263
18 UIKit 0x000000010d4ca553 _UIApplicationHandleEventQueue + 6660
19 CoreFoundation 0x000000010f9b8301 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
20 CoreFoundation 0x000000010f9ae22c __CFRunLoopDoSources0 + 556
21 CoreFoundation 0x000000010f9ad6e3 __CFRunLoopRun + 867
22 CoreFoundation 0x000000010f9ad0f8 CFRunLoopRunSpecific + 488
23 GraphicsServices 0x00000001107e2ad2 GSEventRunModal + 161
24 UIKit 0x000000010d4cff09 UIApplicationMain + 171
25 Lettuce 0x000000010a2c3f0f main + 111
26 libdyld.dylib 0x000000011012492d start + 1
27 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)
After some investigating, I have found the problematic code. It is a line within my cardSwipedRight method that is in my draggableviewbackground class (this class functions as a deck, to hold all of the cards) :
[((settingsTableViewController *)([obj.superNavController.viewControllers[obj.profileNum] viewControllers][0])) askForPushNotifications];
This line of code is within an if statement that checks whether this is a "sign me up for notifications card". What I'm confused by, is why xcode associated filterPageView with askForPushNotifications. Not only does filterPageView not have a askForPushNotifications method, but I don't swipe right on filterPageView nor have I viewed it by the time my app crashes.
One receives an unrecognized selector exception when the object to which the selector is sent does not implement/respond to the sent selector. In simple words, if a class A does not implement a method and someone try to call that method on an object of class A, runtime throws an unrecognized selector exception.
When we are not sure whether an object will respond to a selector, we should have a safety check to see if an object responds to intended selector.
For eg.
if ([*obj* respondsToSelector:#selector(*selector*)])
{
[*obj* performSelector:*selector*];
}
unrecognized selector sent to instance comes up when you try to call a method on an object but that method doesn't exist (The corrrect terminology is that you have tried to send a message called "askForPushNotifications" but the settingsTableViewController does not understand it as it(askForPushNotifications) doesn't exit . I am sure you may not have that method in your settingsTableViewController. Please check and let me know if that helped you.
Also, please check with respondsToSelector if the object actually responds to the method askForPushNotifications. It may be the case that
((settingsTableViewController
*)([obj.superNavController.viewControllers[obj.profileNum] viewControllers][0]))
may not be of type SettingsTableViewController. Please check
if [(((settingsTableViewController *)([obj.superNavController.viewControllers[obj.profileNum] viewControllers][0])) respondsToSelector:#selector(askForPushNotifications)]
{
[((settingsTableViewController *)([obj.superNavController.viewControllers[obj.profileNum] viewControllers][0])) askForPushNotifications];
}
I have a method that is similar to the tee utility. It receives a notification that data has been read on a pipe, and then writes that data to one or more pipes (connected to subordinate applications). If a subordinate app crashes, then that pipe is broken, and I naturally get an exception, which is then handled in a #try...#catch block.
This works most of the time. What I'm puzzled by is that occasionally, the exception crashes the app entirely with an uncaught exception, and pointing to the writeData line . I haven't been able to figure out what the pattern is on when it crashes, but why should it ever NOT be caught? (Note this is not executing inside the debugger.)
Here's the code:
//in setup:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(tee:) name:NSFileHandleReadCompletionNotification object:fileHandle];
-(void)tee:(NSNotification *)notification
{
// NSLog(#"Got read for tee ");
NSData *readData = notification.userInfo[NSFileHandleNotificationDataItem];
totalDataRead += readData.length;
// NSLog(#"Total Data Read %ld",totalDataRead);
NSArray *pipes = [teeBranches objectForKey:notification.object];
if (readData.length) {
for (NSPipe *pipe in pipes {
#try {
[[pipe fileHandleForWriting] writeData:readData];
}
#catch (NSException *exception) {
NSLog(#"download write fileHandleForWriting fail: %#", exception.reason);
if (!_download.isCanceled) {
[_download rescheduleOnMain];
NSLog(#"Rescheduling");
}
return;
}
#finally {
}
}
}
I should mention that I have set a signal handler in my AppDelegate>appDidFinishLaunching:
signal(SIGPIPE, &signalHandler);
signal(SIGABRT, &signalHandler );
void signalHandler(int signal)
{
NSLog(#"Got signal %d",signal);
}
And that does execute whether the app crashes or the signal is caught.
Here's a sample crash backtrace:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
*** Terminating app due to uncaught exception 'NSFileHandleOperationException', reason: '*** -[NSConcreteFileHandle writeData:]: Broken pipe'
abort() called
terminating with uncaught exception of type NSException
Application Specific Backtrace 1:
0 CoreFoundation 0x00007fff838cbbec __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff90e046de objc_exception_throw + 43
2 CoreFoundation 0x00007fff838cba9d +[NSException raise:format:] + 205
3 Foundation 0x00007fff90a2be3c __34-[NSConcreteFileHandle writeData:]_block_invoke + 81
4 Foundation 0x00007fff90c53c17 __49-[_NSDispatchData enumerateByteRangesUsingBlock:]_block_invoke + 32
5 libdispatch.dylib 0x00007fff90fdfb76 _dispatch_client_callout3 + 9
6 libdispatch.dylib 0x00007fff90fdfafa _dispatch_data_apply + 110
7 libdispatch.dylib 0x00007fff90fe9e73 dispatch_data_apply + 31
8 Foundation 0x00007fff90c53bf0 -[_NSDispatchData enumerateByteRangesUsingBlock:] + 83
9 Foundation 0x00007fff90a2bde0 -[NSConcreteFileHandle writeData:] + 150
10 myApp 0x000000010926473e -[MTTaskChain tee:] + 2030
11 CoreFoundation 0x00007fff838880dc __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
12 CoreFoundation 0x00007fff83779634 _CFXNotificationPost + 3140
13 Foundation 0x00007fff909bb9b1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
14 Foundation 0x00007fff90aaf8e6 _performFileHandleSource + 1622
15 CoreFoundation 0x00007fff837e9ae1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
16 CoreFoundation 0x00007fff837dbd3c __CFRunLoopDoSources0 + 476
17 CoreFoundation 0x00007fff837db29f __CFRunLoopRun + 927
18 CoreFoundation 0x00007fff837dacb8 CFRunLoopRunSpecific + 296
19 HIToolbox 0x00007fff90664dbf RunCurrentEventLoopInMode + 235
20 HIToolbox 0x00007fff90664b3a ReceiveNextEventCommon + 431
21 HIToolbox 0x00007fff9066497b _BlockUntilNextEventMatchingListInModeWithFilter + 71
22 AppKit 0x00007fff8acf5cf5 _DPSNextEvent + 1000
23 AppKit 0x00007fff8acf5480 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
24 AppKit 0x00007fff8ace9433 -[NSApplication run] + 594
25 AppKit 0x00007fff8acd4834 NSApplicationMain + 1832
26 myApp 0x00000001091b16a2 main + 34
27 myApp 0x00000001091ab864 start + 52
So, the nice folks at Crashlytics were able to help me here. To quote them:
Here's the story:
The pipe dies because the child process crashes. The very next read/write will cause a fault.
That write occurs, which results in a SIGPIPE (not a runtime exception).
If that SIGPIPE is masked/ignored, NSFileHandle checks errno and creates a runtime exception which it throws.
A function deeper than your tee: method has wrapped this write in a #try/#catch (proved by setting a breakpoint on __cxa_begin_catch)
That function, which turns out to be "_dispatch_client_callout", which makes a call to objc_terminate, which effectively kills the
process.
Why does _dispatch_client_callout do this? I'm not sure, but you can
see the code here:
http://www.opensource.apple.com/source/libdispatch/libdispatch-228.23/src/object.m
Unfortunately, AppKit has a really poor track record of being a good
citizen in the face of runtime exceptions.
So, you are right that NSFileHandle raises a runtime exception about
the pipe dying, but not before a signal is raised that kills the
process. Others have encountered this exact issue (on iOS, which has
much better semantics about runtime exceptions).
How can I catch EPIPE in my NSFIleHandle handling?
In short, I don't believe it is possible for you to catch this
exception. But, by ignoring SIGPIPE and using lower-level APIs to
read/write to this file handle, I believe you can work around this. As
a general rule, I'd recommend against ignoring signals, but in this
case, it seems reasonable.
Thus the revised code is now:
-(void)tee:(NSNotification *)notification {
NSData *readData = notification.userInfo[NSFileHandleNotificationDataItem];
totalDataRead += readData.length;
// NSLog(#"Total Data Read %ld",totalDataRead);
NSArray *pipes = [teeBranches objectForKey:notification.object];
if (readData.length) {
for (NSPipe *pipe in pipes ) {
NSInteger numTries = 3;
size_t bytesLeft = readData.length;
while (bytesLeft > 0 && numTries > 0 ) {
ssize_t amountSent= write ([[pipe fileHandleForWriting] fileDescriptor], [readData bytes]+readData.length-bytesLeft, bytesLeft);
if (amountSent < 0) {
NSLog(#"write fail; tried %lu bytes; error: %zd", bytesLeft, amountSent);
break;
} else {
bytesLeft = bytesLeft- amountSent;
if (bytesLeft > 0) {
NSLog(#"pipe full, retrying; tried %lu bytes; wrote %zd", (unsigned long)[readData length], amountSent);
sleep(1); //probably too long, but this is quite rare
numTries--;
}
}
}
if (bytesLeft >0) {
if (numTries == 0) {
NSLog(#"Write Fail4: couldn't write to pipe after three tries; giving up");
}
[self rescheduleOnMain];
}
}
}
}
I know this doesn't do much to answer why the exception catching seems broken, but I hope that this is a helpful answer to workaround the issue.
I faced a similar issue trying to read/write to a socket wrapped in an NSFileHandle. I worked around it by testing the pipe availability directly with the fileDescriptor like so
- (BOOL)socketIsValid
{
return (write([fh fileDescriptor], NULL, 0) == 0);
}
then I tested with that method before attempting to call writeData:.
I am using a mapview and sporadically get crashes in iOS7 (both simulator + device). It looks like this:
Exception Type:
EXC_BAD_ACCESS (SIGBUS) Exception Codes:
KERN_PROTECTION_FAILURE at 0x000000000000000c
Application Specific Information: objc_msgSend() selector name: points
iPhone Simulator 463.9.4, iPhone OS 7.0 (iPhone Retina
(3.5-inch)/11A465)
Thread 23 Crashed: 0 libobjc.A.dylib 0x03ea10b2 objc_msgSend + 14
1 MapKit 0x02bd9f0d -[MKPolylineView drawMapRect:zoomScale:inContext:] + 54
2 MapKit 0x02bd98ff __43-[MKOverlayView overlay:drawKey:inContext:]_block_invoke + 847
3 MapKit 0x02bd9572 -[MKOverlayView overlay:drawKey:inContext:] + 268
4 VectorKit 0x0c54741d -[VKRasterOverlay drawKey:inContext:] + 61
5 VectorKit 0x0c5455e5 __40-[VKRasterOverlayTileSource _queueDraw:]_block_invoke + 485
6 libdispatch.dylib 0x04ccd818 _dispatch_call_block_and_release + 15
7 libdispatch.dylib 0x04ce24b0 _dispatch_client_callout + 14
8 libdispatch.dylib 0x04cd0ef1 _dispatch_root_queue_drain + 287
9 libdispatch.dylib 0x04cd113d _dispatch_worker_thread2 + 39
10 libsystem_c.dylib 0x04ffae72 _pthread_wqthread + 441
11 libsystem_c.dylib 0x04fe2d2a start_wqthread + 30
As you can see none of my "own" code is executed. Do you have any guesses on how to proceed finding the root of this problem?
From your error's stack, I look at MKPolylineView documentation . It says that this class is deprecated in iOS 7, use MKPolylineRenderer instead...
Not your code ?
Ok, I go up a little in the stack, same thing for MKOverlayView :
In iOS 7 and later, use the MKOverlayRenderer class to display
overlays instead.
It seems MapKit went into some changes !
Are you doing this on the main thread? If not, try this:
dispatch_async(dispatch_get_main_queue(), ^{
// here goes your UI-operation on your mapview
});
I have a button with two buttons which start the download of some data from a web server with RestKit.
Now if the user taps the two buttons repeatedly in quick succession my app crashes and produces the crash log below.
I initiate my requests like so:
-(void)loadDataAtPath:(NSString *)path completion:(ResultArrayBlock)completionBlock failed:(ResultFailedBlock)failedBlock
{
RKObjectMapping *groupMapping = [Group mapping];
[self.objectManager.mappingProvider setMapping:groupMapping forKeyPath:#"groups.group"];
[self.objectManager.mappingProvider setObjectMapping:groupMapping forKeyPath:path];
[self.objectManager loadObjectsAtResourcePath:path usingBlock:^(RKObjectLoader *loader) {
loader.onDidLoadObjects = ^(NSArray *array){
// Do the reverse mapping of the group
for (Group *c in array) {
for(Person *p in c.persons){
p.group = c;
}
}
completionBlock(array);
};
loader.onDidFailWithError = failedBlock;
}];
}
I first thought that the problem was the for-loop where I do some after-mapping setup of my data, but the problem still persists even when commenting the for-loop.
Curiously this problem does not occur in the simulator even when I switch on the Network Link Conditioner.prefpane
The crash
When I debug this on the device I get the following on the console.
[PLCrashReport] Terminated stack walking early: Corrupted frame
[PLCrashReport] Terminated stack walking early: Corrupted frame
The crash log looks like this:
Application Specific Information:
*** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSCFDictionary: 0x3c14a0> was mutated while being enumerated.'
Last Exception Backtrace:
0 CoreFoundation 0x3734e88f __exceptionPreprocess + 162
1 libobjc.A.dylib 0x35053259 objc_exception_throw + 32
2 CoreFoundation 0x3734e3b3 __NSFastEnumerationMutationHandler + 162
3 MyApp 0x0008f5bf -[RKObjectMapper performKeyPathMappingUsingMappingDictionary:] + 407
4 MyApp 0x0008fa45 -[RKObjectMapper performMapping] + 673
5 MyApp 0x0008ac7d -[RKObjectLoader mapResponseWithMappingProvider:toObject:inContext:error:] + 1045
6 MyApp 0x0008b04f -[RKObjectLoader performMapping:] + 575
7 MyApp 0x0008b22b __47-[RKObjectLoader performMappingInDispatchQueue]_block_invoke_0 + 247
8 libdispatch.dylib 0x3046ec59 _dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x30479cab _dispatch_queue_drain + 274
10 libdispatch.dylib 0x30479b19 _dispatch_queue_invoke$VARIANT$up + 36
11 libdispatch.dylib 0x3047a78b _dispatch_worker_thread2 + 214
12 libsystem_c.dylib 0x33bbddfb _pthread_wqthread + 294
13 libsystem_c.dylib 0x33bbdcd0 start_wqthread + 8
As #PhillipMills suggested, you can easily see the answer when you look inside performKeyPathMappingUsingMappingDictionary. Your problem is repeatedly setting the mapping with these lines:
[self.objectManager.mappingProvider setMapping:groupMapping forKeyPath:#"groups.group"];
[self.objectManager.mappingProvider setObjectMapping:groupMapping forKeyPath:path];
If you call this line while the response is being mapping it triggers the error because you are changing the same dictionary it is trying to fast enumerate over.
Normally, you would set the mapping somewhere in the initial configuration and NOT each time like this.