[NSFetchedResultsController] ASTableView crash in ASDeleteElementsInMultidimensionalArrayAtIndexPaths

[ankorko]

On the initial load of an ASTableView I am sometimes getting a crash in ASDeleteElementsInMultidimensionalArrayAtIndexPaths. In the update block [arr removeObjectsAtIndexes:indexSet]; the array is empty but the indexSet is not. I think this is happening when the ASTableView is still loading but the NSFetchedResultsControllerDelegate tries to make an update.

Is there something I am doing wrong?

I do not have a way of reproducing other than starting up the app many times. I am attaching a full stack trace. I will also try to reproduce in a demo project.

bt_all.txt

[appleguy]

@ankorko thank you for including the full backtrace! Are you in the slack room with us? It might be easier to debug there.

The most important question is one version of the framework you're using. Integrating with an NSFRC is an important use case that is supported, but it is definitely one of the more stressful test of the system and older versions of the framework did not fully support it. Make sure you are using 1.9.7.1, and you might try clearing your Pod state and reinstalling.

Is there a particular flow that allows you to reproduce this, or is it fairly random?

Something that would be of great value to the community is a simple example case that uses a fetched results controller. We could then integrate this with unit tests, and it would also help reproduce issues of this nature.

The good news is that I am not aware of any other reports of an issue like this using the framework built in the past month or so. So, I think there is a good chance that we will be able to find a small issue in how the framework has been integrated and solve the problem for you.

[ankorko]

Sorry for the omission. I was on 1.9.7. I have updated to 1.9.7.1 since and have not had the crash again. I will keep an eye on it.

[ankorko]

I can verify that it still happens on 1.9.7.1. But there is now a newer release, so moving to 1.9.7.2 and will keep you posted.

[appleguy]

OK, thank you for confirming. With this information, I think the new version will not address the issue and so we can consider it a current bug. Do you think you would have the opportunity to abstract a bit of your code into an example project?

If we can get a reproduction case, it should only take about a week to have a fix for this issue, because it is extremely important that this part of the framework is bulletproof for all use cases.

Sent from my iPad

On Apr 15, 2016, at 6:24 AM, Antonis Korkofigkas notifications@github.com wrote:

I can verify that it still happens on 1.9.7.1. But there is now a newer release, so moving to 1.9.7.2 and will keep you posted.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[smyrgl]

@ankorko Have you tried processing your updates serially with concurrency control? For example you can setup a dispatch_group on your view controller then when lock/unlock datasource is called on the ASTableViewDatasource you can call dispatch_group_enter/dispatch_group_leave respectively and then batch your changes into a dispatch_group_notify. NSFetchedResultsController doesn't provide a way to model a set of changes out-of-the-box but there are tools that let you do this (I use a variant of https://github.com/wtmoose/TLIndexPathTools).

If you need more help on this ping me on the Slack channel--I have a production setup with ADK and Core Data that is doing similar stuff to what you are trying to do and I got it to work (although a lot of effort went into doing so because of issues like what you mentioned).

[appleguy]

@ankorko: @Adlai-Holler found a similar crash by building a comprehensive thrash tester and it is believed to be fixed by PR #1812. Could you try this out and let Adlai know if you have any further issues?

[ankorko]

@appleguy @Adlai-Holler thanks for looking into this. I have installed ASDK from the commit of the PR being merged and I still got the same error. Here is a stack trace

bt_all.txt

[ankorko]

@appleguy I have come across a flow that could be related to what causes this. I will try to describe the steps, maybe that will be some help. If not, I really need to create a test project. I apologize in advance for not having invested the time to create one.

• Load an ASTableView with FRC.
• It firsts loads the cached data on the disk.
• At the same time a network call is started to fetch more data.
• A very long process takes place in the ASCellNode subclass init.
• The datasource is still locked
• The network call finished, more data is saved to the disk, FRC delegates kicks in and tries to update the ASTableView while the first load is still ongoing.

[terenzeyuen]

Getting this issue too – any fixes?

[maicki]

Hey @ankorko @terenzeyuen is this still an issue if you try it with master? If it is can you please provide an example project? Thanks!

[garrettmoon]

I'm going to close this since there's been no activity. If you need further help, please consider joining our slack and asking questions in the #general channel.