Recent master commit causes crash with ASEditableTextNode inside an ASCellNode

[djblake]

I am working on the master branch and a recent pod update caused my app to start instant crashing at a new main thread assert in the dealloc method of ASTextKitComponents, which I noticed was added recently in the commit here

After struggling to find what was causing it for ages, I eventually worked out that it simply seemed to be caused by having an ASEditableTextNode as a child of an ASCellNode in an ASCollectionNode. To confirm this I managed to retro-fit an example Texture project which I created a few weeks ago to demonstrate another issue. I have attached this here:

TextureGifMemoryBug ASEditableTextNode Crash.zip

The project was originally created to demonstrate a memory issue using gifs. As such when you run the project you'll see an ASCollectionNode with a lot of gifs. To demonstrate the crash issue discussed above, all you have to do is go into the GifCellNode class and unblock the line of code at the top of layoutSpecThatFits: that says:

return [ASWrapperLayoutSpec wrapperWithLayoutElement:self.editableTextNode];

This will switch the cells to instead use a simple ASEditableTextNode created in the init method, and as you will see will instantly crash the app on the assert added in the commit noted above.

@maicki maybe you can help?

[nguyenhuy]

@djblake Thanks for reporting. I can reproduce the problem internally and #610 fixes it. Feel free to reopen if you still hit this issue after updating to latest master.

[hebertialmeida]

This crash still happening to me on latest commit.

[nguyenhuy]

Could you please update the symbolized trace?

[hebertialmeida]

This is where it stop:

The version I am using:

Does it help?

[nguyenhuy]

Yeap, I’ll take a closer look. Thanks for reporting!

[hebertialmeida]

@nguyenhuy I have noticed that when the crash happens on assert the current thread is ASDeallocQueue and not main.

This is the log:

2017-10-17 12:51:52.340400-0400 PostBeyond[2071:329138] requires main thread: 1 class: _ASDisplayView
2017-10-17 12:51:52.341184-0400 PostBeyond[2071:329138] [MainDealloc] <ASEditableTextNode: 0x1059de600>: Trampolining ivar '_layer' value <_ASDisplayLayer: 0x1c085cc50> for main deallocation.
2017-10-17 12:51:52.341300-0400 PostBeyond[2071:329138] requires main thread: 1 class: _ASDisplayLayer
2017-10-17 12:51:52.341844-0400 PostBeyond[2071:329138] [MainDealloc] <ASEditableTextNode: 0x1059de600>: Trampolining ivar '_textKitComponents' value <ASTextKitComponents: 0x1c08586c0> for main deallocation.
2017-10-17 12:51:52.341929-0400 PostBeyond[2071:329138] requires main thread: 1 class: ASTextKitComponents
2017-10-17 12:51:52.342014-0400 PostBeyond[2071:329138] *** Assertion failure in -[ASTextKitComponents dealloc], /Pods/Texture/Source/TextKit/ASTextKitComponents.mm:101

(lldb) thread info
thread #20: tid = 0x505b2, 0x00000001853f04f0 libobjc.A.dylib`objc_exception_throw, name = 'ASDeallocQueue', stop reason = breakpoint 1.1

(lldb) po _textView
<ASPanningOverriddenUITextView: 0x1058fb200; baseClass = UITextView; frame = (0 0; 345 405.5); text = ''; clipsToBounds = YES; opaque = NO; gestureRecognizers = <NSArray: 0x1c085e450>; layer = <CALayer: 0x1c0424300>; contentOffset: {0, 0}; contentSize: {345, 21}; adjustedContentInset: {0, 0, 0, 0}>

[nguyenhuy]

@hebertialmeida Hm, that shouldn't be happening. Based on the log, the text components should be added to the main thread queue. I'm suspecting there is a race condition somewhere. Can you reproduce this problem every time? When it happens, at which line inside _scheduleIvarsForMainDeallocation (frame #4) does the app stop? Can you reproduce it in one of our example projects or via a test case?

[hebertialmeida]

No, It doesn't happen every time, sometimes after couple tries. I have created a sample project that reproduces, there is also a test case that you can execute and will open and dismiss 100x so you don't have to click on that, just execute the test and I hope it crashes.

Seems that when the crash happens it is passing on line 445 for _scheduleIvarsForMainDeallocation:

as_log_debug(ASMainThreadDeallocationLog(), "%@: Not trampolining ivar '%s' value %@.", self, ivar_getName(ivar), value);

TextureSample.zip

[hebertialmeida]

@nguyenhuy Did you have a chance to test it?

[flovouin]

Hey, looks like I'm having the same issue: on master, dealloc'ing an ASEditableTextNode contained in an ASCellNode makes my app crash. (Although I'm mainly basing this observation on what I've read in this issue.) The crash does not occur every time, but very frequently nonetheless (4 out of 5 times). Everything was fine on commit 1c9738.

Here's the stack trace for the dealloc queue when the crash occurs (using commit af99ff):

* thread #29, name = 'ASDeallocQueue', stop reason = signal SIGABRT
    frame #0: 0x0000000190a59014 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000190b23264 libsystem_pthread.dylib`pthread_kill + 112
    frame #2: 0x00000001909cd9c4 libsystem_c.dylib`abort + 140
    frame #3: 0x00000001904991b0 libc++abi.dylib`abort_message + 132
    frame #4: 0x00000001904b2c04 libc++abi.dylib`default_terminate_handler() + 304
    frame #5: 0x00000001904c0820 libobjc.A.dylib`_objc_terminate() + 124
    frame #6: 0x00000001904af5d4 libc++abi.dylib`std::__terminate(void (*)()) + 16
    frame #7: 0x00000001904af640 libc++abi.dylib`std::terminate() + 60
    frame #8: 0x000000010142daa8 AsyncDisplayKit`__clang_call_terminate at _ASAsyncTransaction.mm:0
  * frame #9: 0x00000001014fbab8 AsyncDisplayKit`::-[ASDisplayNode dealloc](self=0x0000000116d1ec00, _cmd="dealloc") at ASDisplayNode.mm:415        <-- This is an ASEditableTextNode
    frame #10: 0x00000001904de134 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 836
    frame #11: 0x0000000101598160 AsyncDisplayKit`::__28-[ASDeallocQueue threadMain]_block_invoke((null)=0x00000001b7d361d8, timer=0x0000000174367740) at ASRunLoopQueue.mm:95
    frame #12: 0x0000000191a0daa4 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
    frame #13: 0x0000000191a0d7a8 CoreFoundation`__CFRunLoopDoTimer + 856
    frame #14: 0x0000000191a0d068 CoreFoundation`__CFRunLoopDoTimers + 244
    frame #15: 0x0000000191a0ac8c CoreFoundation`__CFRunLoopRun + 1484
    frame #16: 0x000000019193ada4 CoreFoundation`CFRunLoopRunSpecific + 424
    frame #17: 0x00000001919879c0 CoreFoundation`CFRunLoopRun + 112
    frame #18: 0x0000000101597e18 AsyncDisplayKit`::-[ASDeallocQueue threadMain](self=0x00000001743010e0, _cmd="threadMain") at ASRunLoopQueue.mm:108
    frame #19: 0x0000000192553318 Foundation`__NSThread__start__ + 996
    frame #20: 0x0000000190b2168c libsystem_pthread.dylib`_pthread_body + 240
    frame #21: 0x0000000190b2159c libsystem_pthread.dylib`_pthread_start + 284
    frame #22: 0x0000000190b1ecb4 libsystem_pthread.dylib`thread_start + 4

[hebertialmeida]

@flovouin Probably it is the same problem.

[shebbys]

Hello, I think I am getting this same issue on 2.5.1:

[phuson]

This issue is happening for me too on 2.5.1 when I'm using ASEditableTextNode (works fine when I switched it out for ASTextNode instead). My app crashes intermittently on an iPhone 6 running iOS v11.0.3. However, the same app appears to be working okay so far on an iPhone 6s running iOS v11.1.

[nguyenhuy]

Quick update: There is a race condition in ASRunLoopQueue that causes some ASTextKitComponents instances to be deallocated on a background thread even though they are always added to a main thread deallocation queue. The core team is aware of this issue and we're discussing on how to best address it. Thanks for reporting everyone!

[hebertialmeida]

@nguyenhuy Thanks!

[PatrickSCLin]

same to me, which version is safe for now?

[nguyenhuy]

Please test against the diff in #651.

[hebertialmeida]

Thanks @nguyenhuy, just tested that and It fixed to me. I think this can be closed...

[nguyenhuy]

Awesome. Thank you!

[flovouin]

Sorry for the delay. It seems to fix the bug on my end too. Cheers!

[stapleup]

Any chance this could be added in next release? because version 2.5.1 is still crashing due to this issue. Thanks

[nguyenhuy]

Yes it’ll be included in the next release.

[nguyenhuy]

In the meantime, please use master if you have to. FYI, Pinterest syncs with master pretty much every week.

[hebertialmeida]

I also use master without problem 😄

[abhpan27]

We are observing similar crash.
It is happening if we disable editing of text node in didLoad().
self.reviewDescriptionScrollableNode.textView.isEditable = false

It is not always reproducible.

Fatal Exception: NSInternalInconsistencyException
0  CoreFoundation                 0x1857bed8c __exceptionPreprocess
1  libobjc.A.dylib                0x1849785ec objc_exception_throw
2  CoreFoundation                 0x1857bebf8 +[NSException raise:format:]
3  Foundation                     0x1861af00c -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:]
4  UIFoundation                   0x1904b2adc -[NSLayoutManager(NSPrivate) _resizeTextViewForTextContainer:]
5  UIFoundation                   0x19048bb74 -[NSLayoutManager(NSPrivate) _recalculateUsageForTextContainerAtIndex:]
6  UIFoundation                   0x1904d0c8c _enableTextViewResizing
7  UIFoundation                   0x1904d2978 -[NSLayoutManager textStorage:edited:range:changeInLength:invalidatedRange:]
8  UIFoundation                   0x1904ecdd0 -[NSTextStorage _notifyEdited:range:changeInLength:invalidatedRange:]
9  UIFoundation                   0x190482d5c -[NSTextStorage endEditing]
10 UIKit                          0x18f62fb14 -[UITextView setAttributedText:]
11 AsyncDisplayKit                0x102cb1374 (Missing)
12 Flipkart                       0x101497b60 specialized ProductRatingNode.layoutSpecThatFits(ASSizeRange) -> ASLayoutSpec (ReviewFullScreenImageWidget.swift:464)
13 Flipkart                       0x101495508 @objc ProductRatingNode.layoutSpecThatFits(ASSizeRange) -> ASLayoutSpec (ReviewFullScreenImageWidget.swift)
14 AsyncDisplayKit                0x102ca3f28 -[ASDisplayNode _locked_layoutElementThatFits:]
15 AsyncDisplayKit                0x102ca3acc -[ASDisplayNode calculateLayoutThatFits:]
16 AsyncDisplayKit                0x102ca38f0 -[ASDisplayNode calculateLayoutThatFits:restrictedToSize:relativeToParentSize:]
17 AsyncDisplayKit                0x102c944f8 -[ASDisplayNode(ASLayoutElement) layoutThatFits:parentSize:]
18 AsyncDisplayKit                0x102cde6f8 (Missing)
19 AsyncDisplayKit                0x102cc423c -[ASLayoutSpec calculateLayoutThatFits:restrictedToSize:relativeToParentSize:]
20 AsyncDisplayKit                0x102cc40d8 -[ASLayoutSpec layoutThatFits:parentSize:]
21 AsyncDisplayKit                0x102cd6008 (Missing)
22 AsyncDisplayKit                0x102cc40d8 -[ASLayoutSpec layoutThatFits:parentSize:]
23 AsyncDisplayKit                0x102ca3bac -[ASDisplayNode calculateLayoutThatFits:]
24 AsyncDisplayKit                0x102ca38f0 -[ASDisplayNode calculateLayoutThatFits:restrictedToSize:relativeToParentSize:]
25 AsyncDisplayKit                0x102c9643c (Missing)
26 libdispatch.dylib              0x1850b0aa0 _dispatch_call_block_and_release
27 libdispatch.dylib              0x1850b0a60 _dispatch_client_callout
28 libdispatch.dylib              0x1850b7b84 _dispatch_queue_override_invoke$VARIANT$mp
29 libdispatch.dylib              0x1850bdcac _dispatch_root_queue_drain
30 libdispatch.dylib              0x1850bd9fc _dispatch_worker_thread3
31 libsystem_pthread.dylib        0x1853e3fac _pthread_wqthread
32 libsystem_pthread.dylib        0x1853e3b08 start_wqthread