[ASDataController] Crash due to new assert in #797

[flovouin]

Hi guys,

I tried using master (2a0c6f) with my app, but I have a crash that sometimes occurs when updating collection nodes. It is a relatively complex setup and unfortunately I don't have a sample project for it.

I tracked down the bug to PR #797, which introduces a new assert in the ASDataController here. In some cases, editingTransactionQueueBusy is YES and _editingTransactionGroupCount is 0, which causes the assert to fail. See the trace below.

I know this is not much to work on, please tell me if there's anything else I can do to investigate.

Cheers,

Flo

    frame #0: 0x0000000181df85b4 libobjc.A.dylib`objc_exception_throw
    frame #1: 0x0000000182c3ebf8 CoreFoundation`+[NSException raise:format:arguments:] + 104
    frame #2: 0x000000018362efa0 Foundation`-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 112
  * frame #3: 0x0000000102488bf8 AsyncDisplayKit`::-[ASDataController isProcessingUpdates](self=0x00000001d4527da0, _cmd="isProcessingUpdates") at ASDataController.mm:458
    frame #4: 0x0000000102488f34 AsyncDisplayKit`::-[ASDataController onDidFinishProcessingUpdates:](self=0x00000001d4527da0, _cmd="onDidFinishProcessingUpdates:", completion=0x000000010248aadc)()) at ASDataController.mm:472
    frame #5: 0x000000010248aa98 AsyncDisplayKit`::__40-[ASDataController updateWithChangeSet:]_block_invoke(.block_descriptor=0x00000001d5051d60, finished=YES) at ASDataController.mm:511
    frame #6: 0x000000010240d294 AsyncDisplayKit`::__46-[_ASHierarchyChangeSet addCompletionHandler:]_block_invoke(.block_descriptor=0x00000001d5051b20, finished=YES) at _ASHierarchyChangeSet.mm:176
    frame #7: 0x000000010240d3b4 AsyncDisplayKit`::-[_ASHierarchyChangeSet executeCompletionHandlerWithFinished:](self=0x00000001d43a9a00, _cmd="executeCompletionHandlerWithFinished:", finished=YES) at _ASHierarchyChangeSet.mm:183
    frame #8: 0x0000000102475974 AsyncDisplayKit`::__64-[ASCollectionView rangeController:updateWithChangeSet:updates:]_block_invoke_2(.block_descriptor=0x00000001d166d080, finished=YES) at ASCollectionView.mm:2139
    frame #9: 0x000000018c96acc4 UIKit`-[UICollectionView _updateAnimationDidStop:finished:context:] + 1740
    frame #10: 0x000000018d2d9394 UIKit`__71-[UICollectionView _updateWithItems:tentativelyForReordering:animator:]_block_invoke.2023 + 92
    frame #11: 0x00000001836744ac Foundation`__NSFireDelayedPerform + 408
    frame #12: 0x0000000182be7aa8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
    frame #13: 0x0000000182be776c CoreFoundation`__CFRunLoopDoTimer + 864
    frame #14: 0x0000000182be7010 CoreFoundation`__CFRunLoopDoTimers + 248
    frame #15: 0x0000000182be4b60 CoreFoundation`__CFRunLoopRun + 2168
    frame #16: 0x0000000182b04da8 CoreFoundation`CFRunLoopRunSpecific + 552
    frame #17: 0x0000000184ae7020 GraphicsServices`GSEventRunModal + 100
    frame #18: 0x000000018cae578c UIKit`UIApplicationMain + 236
    frame #19: 0x0000000100e66340 MyApp`main at AppDelegate.swift:15
    frame #20: 0x0000000182595fc0 libdyld.dylib`start + 4```

[shenglinFL]

same problem

[oshtman]

I'm experiencing the same problem

[dox-mark]

I had this happen sporadically just by adding an ASDisplayNode that wraps a WKWebView. If I remove that node I never get the exception.

[haashem]

I have same issue #914
it occurs when I reload collection node, multiple times, following one by one

[appleguy]

Hey all, thanks for reporting this. I just came across a notification for this issue from Huy reassigning it. I'll see if an engineer from my team may be able to take a look in the next week.

If anyone is able to make this trigger in one of the example projects (like adding a timer-triggered refresh call to ASDKgram, or modifying ASCollectionViewExample), that would certainly be helpful in order to confirm the fix. The app I'm most focused on right now has unfortunately not hit a report of this issue yet, so verifying it will be the most important part.

[flovouin]

Hi @appleguy

Thanks for the reply. Unfortunately I don't have much more to share. I've reproduced the problem multiple times in my app, but it does not always occur, and I can't find a way to trigger it with certainty.

Here's a more detailed stack trace:
https://gist.github.com/flovouin/31114d15da394a3ba784b7c14adc0b4a
(If I'm not mistaken, thread #3, queue = 'org.AsyncDisplayKit.ASDataController.editingTransactionQueue:0x1c4133b00' is not the transaction queue of the data controller that crashes thread #1).

If there's anything I can try on my codebase that you can think of and that would make debugging easier, I'd be happy to experiment further more.

Cheers,

[appleguy]

@flovouin thanks again for reporting this. We found out that, ironically, this assertion was invalid even though the code was valid. That is to say, the assertion required transactional integrity between two bits of state (the atomic counter, and the queue), which is actually not required if only the counter is being referenced. So, all should be well if you update.

[flovouin]

Thanks for the follow up! This makes sense and I probably should have seen this... oh well.
Thanks for the fix!