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...