applyDerivedChangesToCache index out of bounds

[roobiq]

applyDerivedChangesToCache index out of bounds

[bigfish24]

How do you handle write transactions in the app? Are they all performed on a serial background queue?

[ncperry]

It's on the main thread.

[bigfish24]

Ok that rules out threading issues since main is serial. What version of FRC are you using and which version of Realm?

[ncperry]

Hmm we pulled RBQ into our project so we weren't tracking it using CocoaPods or Carthage. (We're using it inside a swift framework, so we didn't want to do CocoaPods inside a framework.) Is there an easy way to check the version?

I'm on 0.94.1 for Realm.

[bigfish24]

If it is a submodule you can type:

git submodule status

to get the commit ID

[ncperry]

We didn't submodule it. We literally just pulled in the code.

[bigfish24]

Hmm do you know roughly when you pulled the code?

[ncperry]

Looks like 5/28/15

[ncperry]

So maybe we do need to track the source somehow. CocoaPods still won't work for us. I noticed in another thread that you are working on Carthage support. Is that working now?

[ncperry]

Did some more digging. And I have no idea if this is relevant. I am writing on the main thread, but it looks like there are multiple background listeners. This is from Crashlytics:

[bigfish24]

No that is normal. Every Realm instance creates a notification listener on background thread to handle automatically refreshing data changes from one realm instance to the next. I was traveling yesterday, will look into it a bit more. Would say though that given how old your pull of the code is, you should update to the latest. However, the latest (2.0) requires Realm 0.95.

[ncperry]

K I'll try to update. Thanks.

[bigfish24]

Can you check if the error is occurring due to a section delete or a row delete? (i.e. in applyDerivedChangesToCache:state: is the error in the loop over derived section changes or derived object changes)

[ncperry]

Looking at the stack trace we are updating an object. We section by date. So if an object gets it's date updated, that could certainly result in a section being deleted and a different section being created or updated.

Another interesting anomaly is we have seen this crash 5741 and we have had 5741 users see the crash. So each user that does have it happen, sees it happen exactly once. And then is good.

[bigfish24]

Can you tell me what is the code at line 915 for you?

[bigfish24]

Did the code update fix the issue?

[ncperry]

Hey sorry, things got a little crazy here. If the database got deleted while the FRC was tracking could that cause this issue?

Cause after looking a bit more at the code, that could have happened.

As far as the fix working, we weren't seeing this bug at all but rather in 0.1% of our user base, so it was unreproducible here in the office. So we won't know about fixes working until we push a new build to the store.

[bigfish24]

Sorry for my delay in responding. I was traveling in Europe. If the database got deleted while the FRC was tracking that would probably be the cause. The FRC creates a cache representation of the table state (including the sections) in a second Realm (either in-memory or persisted), and then when changes occur in the main Realm, this cache is used to find the differences. If you delete the main Realm file and create a new one, the cache might not have been rebuilt, so it would throw an index out of bounds error potentially when trying to figure out the changes applied to the new main Realm.

Does this make sense?

To fix, you should call reset on the FRC after the main Realm is deleted/recreated. This will delete the cache and rebuild it, so that it matches the new Realm.

[bigfish24]

I believe I have fixed the bug in the latest release.