Ok, I've figured out that I can use something like @"latitude": @(nan("0x12345")) to replace @"latitude": @(locationObject.location.coordinate.latitude)in order to reproduce the exception. The modified code from above is now:     NSMutableDictionary *body = [NSMutableDictionary new];     [body setObject:Utils.deviceDict forKey:@"device"];     NSMutableArray *trackingQueueCopy = trackingQueue.copy;     NSMutableArray *locationObjects = [NSMutableArray new];     NSError *error;     for(LocationObject *locationObject in trackingQueueCopy) {         NSDictionary *locationDict = @{@"latitude": @(locationObject.location.coordinate.latitude),                                        @"longitude": @(locationObject.location.coordinate.longitude),                                        @"locationTimestamp": @(round(locationObject.location.timestamp.timeIntervalSince1970)),                                        @"altitude": @(locationObject.location.altitude),                                        @"horizontalAccuracy": @(locationObject.location.horizontalAccuracy),                                        @"verticalAccuracy": @(locationObject.location.verticalAccuracy),                                        @"clientTimestamp": @(round(locationObject.dataTimestamp.timeIntervalSince1970)),                                        @"battery": @(round(locationObject.batteryLevel*100)/100),                                        @"speed": @(locationObject.location.speed),                                        @"course": @(locationObject.location.course)                                        };         @try {             [NSJSONSerialization dataWithJSONObject:locationDict options:NSJSONWritingPrettyPrinted error:&error];             [locationObjects addObject:locationDict];         } @catch(NSException *exception) {             DLog(@"invalid JSON payload, ignoring (%@)", exception);         }     } That's sufficient enough for me to have this bug fixed. Figuring out what exactly is actually causing the NaN would be a different story though, and I'm currently not sure how I could approach that...

Thank you very much for the explanation, it totally makes sense. Also, the pattern in the backtrace gives you a rough idea of the nesting, namely dictionary > array > dictionary > number. Yes, that does indeed exactly match the structure as seen in the code snippet above. Now in order to reproduct the issue, I wonder how I can generate a NaN or infinite value? The potential candidates in the locationDictfrom above are CLLocationDegrees, CLLocationDistance, CLLocationAccuracy, CLLocationSpeed, CLLocationDirection, NSTimeInterval, float. So basically we have double or float.

Right. Well, it’s possible for +new to fail and return nil, but that can only happen if malloc fails, meaning that you’ve exhausted your address space. That’s unlikely to result in a consistent crash like this. Ok, I agree. But I also agree that it's very unlikely. The crash report is attached. Thank you very much for your support! crash.txt

Thank you very much for taking the time to write such a detailed explanation. It is much appreciated! Here's the code where the crash is happening:     NSMutableDictionary *body = [NSMutableDictionary new];     [body setObject:Utils.deviceDict forKey:@"device"];     NSMutableArray *trackingQueueCopy = trackingQueue.copy;     NSMutableArray *locationObjects = [NSMutableArray new];     for(LocationObject *locationObject in trackingQueueCopy) {         NSDictionary *locationDict = @{@"latitude": @(locationObject.location.coordinate.latitude),                                        @"longitude": @(locationObject.location.coordinate.longitude),                                        @"locationTimestamp": @(round(locationObject.location.timestamp.timeIntervalSince1970)),                                        @"altitude": @(locationObject.location.altitude),                                        @"horizontalAccuracy": @(locationObject.location.horizontalAccuracy),                                        @"verticalAccuracy": @(locationObject.location.verticalAccuracy),                                        @"clientTimestamp": @(round(locationObject.dataTimestamp.timeIntervalSince1970)),                                        @"battery": @(round(locationObject.batteryLevel*100)/100),                                        @"speed": @(locationObject.location.speed),                                        @"course": @(locationObject.location.course)                                        };         [locationObjects addObject:locationDict];     }     [body setObject:locationObjects forKey:@"locations"];     NSError *error;     NSData *jsonData = [NSJSONSerialization dataWithJSONObject:body options:NSJSONWritingPrettyPrinted error:&error]; The crash occurs in fact on the very last line. But as can be seen on the first line of that snipped, body cannot be nil (at least to my understanding). My guess is that somehow the content of body cannot be converted into JSON which is causing the crash but I have not been able to figure how how that can happen. Unfortunately I don't have a specific user who can send a sysdiagnose so I would like to go by your suggestion of reproducing the crash and comparing the offset to the crash reports. But the thing is, I still have no clue where it could happen and therefore how to reproduce. By looking a this snippet of code, do you see anything suspicious?

Thanks, but I know that already. What I was trying to ask is something different: When I look at the crashes of my published app in the Xcode Organizer by selecting a crash and then using "Open in Project..." I see on which line of code the crash did happen. But is it also possible for those crashed to get a "terminating app due to..." reason?

I am facing the same issue. The extension does not seem to be able to openURL the main app. Is there a solution for this problem or is it still not possible?

The app is a universal app with just one target. I did open a code level technical support request for this issue. I can work around it with this crazy piece of code: @try { cell = [tableView dequeueReusableCellWithIdentifier:reuseIdentifierTextCell forIndexPath:indexPath]; } @catch(id exception) { NSArray *topLevelObjects = [[NSBundle mainBundle] loadNibNamed:@"ChatTextCellCondensed" owner:self options:nil]; cell = [topLevelObjects objectAtIndex:0]; }