[ASTableView] Inconsistent data state during table manipulation.

[victoria-chain]

The problem is in updating visible cell nodes after it's deletion.

Dispatched block [self performSelector:@selector(updateVisibleNodeIndexPaths) withObject:nil afterDelay:0 inModes:@[ NSDefaultRunLoopMode ]];

is performing right after DELETE_NODES(_nodes, indexPaths, animationOption); in ASDataController::reloadRowsAtIndexPaths.
Actually, there is no possibility to say when updateVisibleNodeIndexPaths will be dispatched exactly.

We have empty _nodes array at this moment and NSRangeException raises

2015-06-15 15:06:51.448 NFLMobile[49145:813629] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSArray objectsAtIndexes:]: index 4 in index set beyond bounds for empty array'
*** First throw call stack:
(
    0   CoreFoundation                      0x0000000104693c65 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x00000001082a0bb7 objc_exception_throw + 45
    2   CoreFoundation                      0x00000001045dd413 -[NSArray objectsAtIndexes:] + 979
    3   NFLMobile                           0x0000000102e2dde5 __ASFindElementsInMultidimensionalArrayAtIndexPaths_block_invoke + 55
    4   NFLMobile                           0x0000000102e2d893 _ZL52ASRecursivelyUpdateMultidimensionalArrayAtIndexPathsP14NSMutableArrayPK7NSArrayRmP11NSIndexPathmU13block_pointerFvS0_P10NSIndexSetmE + 656
    5   NFLMobile                           0x0000000102e2d729 _ZL52ASRecursivelyUpdateMultidimensionalArrayAtIndexPathsP14NSMutableArrayPK7NSArrayRmP11NSIndexPathmU13block_pointerFvS0_P10NSIndexSetmE + 294
    6   NFLMobile                           0x0000000102e2dcfc ASFindElementsInMultidimensionalArrayAtIndexPaths + 322
    7   NFLMobile                           0x0000000102e171f0 -[ASDataController nodesAtIndexPaths:] + 69
    8   NFLMobile                           0x0000000102e370ef -[ASTableView rangeController:nodesAtIndexPaths:] + 31
    9   NFLMobile                           0x0000000102e338b9 -[ASRangeController updateVisibleNodeIndexPaths] + 1161
    10  Foundation                          0x0000000107d011e5 __NSFireDelayedPerform + 387
    11  CoreFoundation                      0x00000001045fb174 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
    12  CoreFoundation                      0x00000001045fad35 __CFRunLoopDoTimer + 1045
    13  CoreFoundation                      0x00000001045bcd3d __CFRunLoopRun + 1901
    14  CoreFoundation                      0x00000001045bc366 CFRunLoopRunSpecific + 470
    15  GraphicsServices                    0x000000010a773a3e GSEventRunModal + 161
    16  UIKit                               0x000000010590a900 UIApplicationMain + 1282
    17  NFLMobile                           0x0000000102acbccf main + 127
    18  libdyld.dylib                       0x0000000109724145 start + 1
    19  ???                                 0x0000000000000001 0x0 + 1
)

I've found a way to fix this issue by adding a check on array count in callback. It's just a stub, may be the problem should have a different solution.

NSArray *ASFindElementsInMultidimensionalArrayAtIndexPaths(NSMutableArray *mutableArray, NSArray *indexPaths) {
  NSUInteger curIdx = 0;
  NSIndexPath *indexPath = [[NSIndexPath alloc] init];
  NSMutableArray *deletedElements = [[NSMutableArray alloc] initWithCapacity:indexPaths.count];

  if (!indexPaths.count) {
    return deletedElements;
  }

  ASRecursivelyUpdateMultidimensionalArrayAtIndexPaths(mutableArray, indexPaths, curIdx, indexPath, [indexPaths[0] length], ^(NSMutableArray *arr, NSIndexSet *indexSet, NSUInteger idx) {
      if (arr.count > 0) // <<< check count
      {
          [deletedElements addObjectsFromArray:[arr objectsAtIndexes:indexSet]];
      }
  });

  ASDisplayNodeCAssert(curIdx == indexPaths.count, @"Indexpath is out of range !");

  return deletedElements;
}

[victoria-chain]

Also i've tried to turn on asyncDataFetchingEnabled as it mentioned in #428 . Crash stays the same.

[victormayorov]

Fixed here #489

[appleguy]

Thanks for reporting--I am investigating this today and tomorrow.

Could you test out the pull request mentioned? Use the checkout with GitHub app button near the bottom (if you haven't seen it before, it's really odd and was unintuitive for me to find).

It would be very helpful to confirm that the patch does not cause any other regressions in your app, in addition to the fix.

[appleguy]

OK, quick look at this suggests that performDataFetchingWithBlock (which locks the data source) is releasing the lock earlier than the original author expected — in effect, the dispatch_async that includes the DELETE_NODES macro escapes the influence of the lock in a way that isn't visually clear.

The coalescing behavior is important for performance, but it does appear to be causing a thread race here. I will investigate tomorrow and develop a fix that uses either queue-based serialization or more careful locking.

[appleguy]

OK, awesome. I was able to create a test case that reproduces this nearly 100% of the time (I haven't hit a case where it didn't, but it does take variable periods of time — no more than 1-2 seconds on a Mac). I also took some of your test implementation, which is much appreciated, and integrated it into my new PR from tonight's work on ASDataController.

I pushed to try to fix the serialization completely, but was unable to finish. This thing is fairly complicated, as you have observed. Nonetheless I did break off a part of the diff that is my work-in-progress (so the PR #496 includes only the cleaned up portions).

Thanks both @victoria-chain and @victormayorov! I am so glad to be close to a fix on this issue, and probably wouldn't have gotten momentum on starting it without your help.

[appleguy]

@victoria-chain & @victormayorov — This is fixed, fixed, and also fixed. :) Or so I'm nearly certain...and would really love your help testing the fix in your environment!

I haven't merged it yet, but you could apply the PR locally to try it out: #529

If it's more convenient to have it in master, just let me know and I'll push the diff. I have tested it quite well and the folks I'm asking to review it can always add comments after the merge for adding to a later follow-up. Of course, please feel free to do a review of the patch as well, although it's probably not the best use of your time — not any fun, at least!

I will release a new version of ASDK within a week (next weekend at the latest; probably sooner). Therefore, having input on any other issues you're encountering with your codebase will be really great.

[victoria-chain]

@appleguy i've checked PR #529 and unfortunately crash still occures. Backtrace is different, but the key reason is the same - we're trying to get data from empty array in ASRangeController. I will try to make a test to provide you a demo of this crash.

[appleguy]

@victoria-chain I've made further modifications to #529 and have now pushed it, as I was not able to find a case that crashes or hangs it. Check out the examples/ASTableViewStressTest project to see if you can tweak it to simulate a scenario similar to what you're doing that is causing a crash, if it is still occurring.

I'll leave this open until we have taken care of any and all issues you can find. I appreciate your help in this regard, and will make this my top priority for the framework (maintaining 0 faults in this area).

[ronenmiz]

I have the same issue and observed that it only reproduces if a sequence of insert/delete operations is followed by reloadRowsAtIndexPaths, e.g.:
[_tableView reloadRowsAtIndexPaths:[_tableView indexPathsForVisibleRows] withRowAnimation:NO];

That reload leads to NSRangeException in ASFindElementsInMultidimensionalArrayAtIndexPaths (I can provide the full stack trace if this is of interest). Perhaps this can help in creating a test case that can reproduce the problem.

Furthermore as I was debugging the above, I noticed a different issue that may be related. The interesting part of the stack trace was starting at updateVisibleNodeIndexPaths: from ASRangeController.mm. I noticed there that in most cases _rangeIsValid is checked prior to using _rangeTypeIndexPaths yet in one case it is not checked. I assume this is a bug but do not know the code well enough, hence wanted to raise it here.

[appleguy]

@victoria-chain, @ronenmiz: Thanks for contributing to the AsyncDisplayKit community by reporting this bug! Due to the length of time it’s been since this thread was active, I’m going to mark this issue as closed.

If you are able to, please try out the latest master as PR #1060 resolved a similar bug. If you are still having troubles, feel free to reopen this issue. I hope you have been able to use the framework!