I am Getting crash in app upgrade scenario. It gives below error and warning. But this issue happens only when I have AppStore build installed and on top of that I install my new testflight build.
If I install developer build on AppStore build, than it works fine.
Error:
[__NSArrayM UTF8String]: unrecognized selector sent to instance
Warning: An RLMRealm instance was deallocated during a write transaction and all pending changes have been rolled back. Make sure to retain a reference to the RLMRealm for the duration of the write transaction.
It crashes straight away when you tap app icon, So, I dont have any stack trace.
Realm version: 0.96.3 &
Xcode version: 7.3
Below is my migration code for that.
RLMRealmConfiguration *config = [RLMRealmConfiguration defaultConfiguration];
config.schemaVersion = 3;
if (oldSchemaVersion < 2)
{
[migration enumerateObjects:DB_Class1.className
block:^(RLMObject *oldObject, RLMObject *newObject) {
newObject[#"thisIsArray_1"] = nil;
}];
[migration enumerateObjects:DB_Class2.className
block:^(RLMObject *oldObject, RLMObject *newObject) {
newObject[#"thisIsInt_1"] = 0;
newObject[#"thisIsInt_2"] = 0;
newObject[#"thisIsInt_3"] = 0;
}];
}
All of the above newObjects are added in this version only.
Update 1: I can see deleteRealmIfMigrationNeededfor android. Is there any eqvivalent in iOS? I only found deleteAllObjects. If so, thn I can simply delete my old realm data and save new one.
Thanks.
Realm Cocoa added the deleteRealmIfMigrationNeeded option (on RLMRealmConfiguration) in version 0.102.0. This should allow you to sidestep your migration issues. See the change notes here.
Related
I updated firebase and since then my app keeps crashing with the following error
Fetcher delegate class: NRMAURLSessionTaskDelegate Fetcher made an
extra session: GTMSessionFetcher 0x125d53db0 Couldn't assign
delegate.
Fetcher delegate class: NRMAURLSessionTaskDelegate
-[GTMSessionFetcher setFetcher:forTask:]: unrecognized selector sent to instance 0x125d53db0
* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[GTMSessionFetcher
setFetcher:forTask:]: unrecognized selector sent to instance
0x125d53db0'
* First throw call stack: (0x18260ad8c 0x1817c45ec 0x182618098 0x1826105c8 0x1824f641c 0x104637b14 0x104613928 0x10461011c
0x102d9364c 0x102d96bdc 0x102d95140 0x102d92a54 0x102db3f90
0x102db36b0 0x102da0e00 0x105bfd1dc 0x105bfd19c 0x105c0bdfc
0x105c006ac 0x105c0bc20 0x105c006ac 0x105c0cd54 0x105c13e38
0x18222fe70 0x18222fb08) libc++abi.dylib: terminating with uncaught
exception of type NSException
the call that I make and crashes is the following:
let reviewsRef = Database.database().reference()
reviewsRef.child("reviews").queryOrdered(byChild: "timestamp").queryLimited(toLast: count)
I added a debug log and the call is made only once.
It seems the line that the app is crashing is
let ref = Database.database().reference()
Did anything changed regarding configuring Firebase from 4.9 to 5.0 version?
Another update:
It seems to be working on the Xcode simulator but not on device. Device is iPhone 6s with 11.4
Kind of working since on simulator I receive the whole database instead of only the "reviews" that I am requesting
if the rules are:
{
"rules": {
".read": true,
but when I change to:
"rules": {
"reviews": {
".read": true,
I get permission denied(on simulator).It has to do maybe with authentication? I understand that those 2 might be two different issues.
I have no idea why this happened on the first place. But I created a new project in firebase with exact same rules and it worked... for some reason the specific project became corrupt on firebase side.
NRMAURLSessionTaskDelegate indicates usage of New Relic - if it worked on a clean project there might be an incompatibility with Firebase
I am having an issue where a crash only occurs when the application is installed via HockeyApp, not via Xcode.
This is the report I get from HockeyApp:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFArray objectAtIndex:]: index (-1970199490 (or possibly larger)) beyond bounds (15)'
MainViewController.m, line 646
Which refers to this line:
for (int i; i < [resultsArray count]; i++) {
if ([[resultsArray[i] valueForKey:#"uniqueId"] isEqualToString:[[NSUserDefaults standardUserDefaults]
stringForKey:#"FbId"]]) {
resultsArray = resultsArray[i];
}
}
Any ideas why I would be getting a crash there when a build is installed via HockeyApp but not via Xcode? I've even tried building the app to a device using both development and distribution certs, but both work fine as long as the build isn't installed via HockeyApp.
I think the issue would be not initializing the value of the i in the for loop.
it should be for (int i=0;....
if it is not initialised, then the value of i would be unpredictable, it could be either null or it could be the value of its memory address.
if you didn't initialise it, then there will be infinite loop (if there is no crash) here as the value of i will be some random negative number -1970199490,
Also even if you do it from xcode, it results in the same behaviour.
I'm getting a crash on my App Store update, the migration is handled and even when I see the code Block is being executed I get the Following migration error
'RLMException', reason: 'Migration is required for object type
'LLCachedObject' due to the following errors:
- Property 'resultType' has been added to latest object model.'
This is how I'm handling the Migration
[migration enumerateObjects:LLCachedObject.className
block:^(RLMObject *oldObject, RLMObject *newObject) {
if (oldSchemaVersion < 5) {
newObject[#"resultType"] = kLLResultTypeBrief;
}
}];
and I double-checked that the oldSchemaVersion was 4, and newObject[#"resultType"] is being set properly, this is happening on iOS 9, I'm completely clueless as I've run out of things to checked to find out what is causing this.
So the problem turned out being that we have another project we use for the same app that also has a Realm, we weren't aware that the migration needed to be handled in both sides, so what we are doing now is using the class subsets to specify the Model Clases that every project uses.
For more details https://realm.io/docs/objc/latest/#class-subsets
I'm trying to remove a property in one of my Realm objects however I'm not sure how to write a migration for this.
I just removed the property from my object's header file but that didn't work as I get this error:
Terminating app due to uncaught exception 'RLMException', reason:
'Migration is required for object type 'Stock' due to the following
errors:
- Property 'percentageOn' is missing from latest object model.'
I know how to write a migration add fields, but how do I remove one?
What David said is correct. If you make sure to perform a migration properly, then Realm can easily handle properties that have been removed as well as added. Unless you actually still need the value in percentageOn, you can even leave the migration block empty like in the example on the Realm website:
// Inside your [AppDelegate didFinishLaunchingWithOptions:]
// Notice setSchemaVersion is set to 1, this is always set manually. It must be
// higher than the previous version (oldSchemaVersion) or an RLMException is thrown
[RLMRealm setSchemaVersion:1
forRealmAtPath:[RLMRealm defaultRealmPath]
withMigrationBlock:^(RLMMigration *migration, NSUInteger oldSchemaVersion) {
// We haven’t migrated anything yet, so oldSchemaVersion == 0
if (oldSchemaVersion < 1) {
// Nothing to do!
// Realm will automatically detect new properties and removed properties
// And will update the schema on disk automatically
}
}];
// now that we have called `setSchemaVersion:withMigrationBlock:`, opening an outdated
// Realm will automatically perform the migration and opening the Realm will succeed
[RLMRealm defaultRealm];
I have been running into an issue in using StackMob as the backend of my iOS application (though I'm not sure if this is an issue in wrongly using StackMob's methods or an iOS issue).
I am allowing a user to create a post object that is just a subclassed NSManagedObject, and uploading that to the server to be used in other parts of the application. The issue that arises occurs in the method:
[NSManagedObjectContext saveOnSuccess:<^(void)successBlock> onFailure:<^(NSError *error)failureBlock>];
Here, I am using a StackMob method for asynchronously saving the MOC found in the NSManagedObjectContext(Concurrency) Category Reference.
The view before this one performs a fetch on recent posts, and in the case where the fetch is not performed posting works fine, but if a fetch was performed then in saving the MOC in order to upload the new post I receive the following output as an error message:
2013-09-11 17:08:09.284 imageTagging[1824:1843] -[__NSDictionaryI bytes]: unrecognized
selector sent to instance 0x1e3123d0
2013-09-11 17:08:09.291 imageTagging[1824:1843] *** Terminating app due to uncaught
exception 'NSInvalidArgumentException', reason: '-[__NSDictionaryI bytes]: unrecognized
selector sent to instance 0x1e3123d0'
*** First throw call stack:
(0x318cb3e7 0x395c6963 0x318cef31 0x318cd64d 0x31825208 0x321631cf 0x3216b991 0x15ea99
0x318c8757 0x15e109 0x15dabf 0x10d1c3 0x318d05b7 0x10cd4d 0x10c829 0x10923b 0x1076d9
0x3166c431 0x316c44d1 0x1685c3 0x316c7e5d 0x399e3b3b 0x399e167d 0x399e4613 0x399e47d9
0x39a087f1 0x39a08684)
libc++abi.dylib: terminate called throwing an exception
(lldb)
The data is still uploading to the StackMob server, and can be called upon when the app is run later -- but the app crashes in trying to save it. All of this is performed in the view controller. I've tried to enforce all MOC saves to be performed on the main thread, but the error still occurs. I've also tried dispatching a "save queue" and updating the UI after save completes. This method seemed to work for a bit, but then the errors came up again (may have just been a fluke). I also tried to do this with the synchronous save calls in the documentation
The same error occurs when trying to perform other saves as well (such as after creating a new user or when updating a user's information), and all come down to the same function call causing the problems. It may also be worthwhile to note that the error is always the same (specifically that a type __NSDictionaryI is trying to access its unrecognized selector bytes.
Here is the full method call with the input parameters filled out:
//save context
[[[[SMClient defaultClient] coreDataStore] contextForCurrentThread] saveOnSuccess:^{
NSLog(#"You created a new Post object!");
[[[[SMClient defaultClient] coreDataStore] contextForCurrentThread] refreshObject:newPost mergeChanges:YES];
NSLog(#"refreshed");
} onFailure:^(NSError *error) {
NSLog(#"There was an error! %#", error);
}];
UPDATE: I have narrowed down the problem to a mishandling of information returned from a fetch performed by the previous view controller. Specifically, it occurs after the results are fetched in trying to use the data to update.
As a result of this new insight, the question I am really facing is how to properly save a managed object in the context after a fetch. I believe StackMob takes care of creating the managed objects after the fetch (i.e. server query). I've tried creating a new object from the results array (each "obj" is an NSManagedObject) with:
[results enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
NSManagedObject *newObj = obj;
}];
I've also tried referencing the fetched results by object id (each "obj" is an objectID) with:
[results enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
NSManagedObject *newObj = [self.managedObjectContext objectWithID:obj];
}];
Any insight on how to properly do this would be greatly appreciated!
UPDATE 2: It looks like the error is actually occurring in trying to use and save geolocation data. In order to use the queried objects' geolocation data, it must be unarchived -- but to save it, it must be archived. I'm looking into how to do this now, and if I come across a good solution, I'll update again.
FINAL UPDATE: Got it figured out! It turns out that the issue I was having was that I was unarchiving the geolocation data to update the UI and do some calculations, and while I was archiving it again to be stored properly, I created an annotation on a map that referenced the unarchived data. As a result, the MOC maintained the data that could not be saved via the StackMob methods. By only saving the archived data, I can save as often as I'd like and just unarchive the geodata when it needs to be used. Problem solved!
Please feel free to comment if anyone comes across a similar problem and needs some insight or references!
I am just going to put my final update in here as an answer, since it explains how I solved the issue.
FINAL UPDATE: Got it figured out! It turns out that the issue I was having was that I was unarchiving the geolocation data to update the UI and do some calculations, and while I was archiving it again to be stored properly, I created an annotation on a map that referenced the unarchived data. As a result, the MOC maintained the data that could not be saved via the StackMob methods. By only saving the archived data, I can save as often as I'd like and just unarchive the geodata when it needs to be used. Problem solved!
Please feel free to comment if anyone comes across a similar problem and needs some insight or references!
Moral of the story, if you are running into issues similar to this, make sure you are not (even if you don't mean to be) storing references to the unarchived SMGeoPoint data in any of your managed objects. It is trying to store those that causes the problem.