[Crash] ASDN::Mutex::~Mutex() #136
Comments
|
From @hannahmbanana on August 2, 2016 3:45 @dssheng: Thanks for reporting this. If you run into this again, it would be helpful if you could record the full backtrace using |
|
From @dssheng on August 2, 2016 5:32 @hannahmbanana |
|
From @hannahmbanana on August 2, 2016 7:43 @dssheng: Thanks for updating. Could you click the dotted line to expand the trace? I believe there was an important locking fix for ASTextNode in the 1.9.81 release. I would recommend upgrading to this right away and updating us if you see this again. |
|
From @dssheng on August 3, 2016 7:22 |
|
From @hannahmbanana on August 3, 2016 7:25 @dssheng: is this 1.9.80 or 1.9.81? |
|
From @dssheng on August 3, 2016 11:51 @hannahmbanana |
|
From @appleguy on August 5, 2016 6:12 @dssheng thanks for the details! @johnepinterest is investigating in this area. Updating the framework would be good. Do you happen to use the name _propertyLock for any of your instance variables? We address this in the latest version, but if you are shadowing this variable, it could cause an issue like this in the last version. (1.9.80, fixed as one of a number of improvements in 1.9.81) Pinterest is currently shipping off of the branch called 1.9.90. If you are willing to point to a branch in your Podfile, this is considered stable and is the best version at the moment. We will push a pod in a week or two. 1.9.81 is an ok choice as well, but .90 has both performance and some stability improvements. |
|
From @olemaga on September 29, 2016 7:13 Saw this one reported through our crash reporting today. Currently using 1.9.90. Assertion failed: (res == 0), function ~Mutex, file ../../Pods/AsyncDisplayKit/AsyncDisplayKit/Details/ASThread.h, line 176. |
|
From @dssheng on January 18, 2017 10:48 AsyncDisplayKit (2.0.1) |
|
From @plm75 on February 1, 2017 11:4 I also have multiple seemingly random crashes due to this. I'm using ASDK 2.0.1 #0. Crashed: com.apple.main-thread -- #0. Crashed: com.apple.main-thread #1. org.AsyncDisplayKit.ASDisplayLayer.displayQueue #2. com.apple.uikit.eventfetch-thread #3. RLMRealm notification listener #4. AVAudioSession Notify Thread #5. Thread #6. WebThread #7. com.twitter.crashlytics.ios.MachExceptionServer #8. com.apple.NSURLConnectionLoader #9. JIT Worklist Worker Thread #10. WTF Parallel Helper Thread #11. WebCore: LocalStorage #12. PINRemoteImageManager Concurrent Operation Queue :: NSOperation 0x1704464e0 (QOS: UTILITY) #13. ASDeallocQueue #14. com.apple.root.default-qos #15. org.AsyncDisplayKit.ASDataController.editingTransactionQueue:0x170137480 #16. org.AsyncDisplayKit.ASDisplayLayer.displayQueue #17. PINRemoteImageManager Concurrent Operation Queue :: NSOperation 0x1706533e0 (QOS: UTILITY) #18. PINRemoteImageManager Concurrent Operation Queue :: NSOperation 0x17024fc30 (QOS: UTILITY) #19. org.AsyncDisplayKit.ASDisplayLayer.displayQueue #20. com.apple.root.default-qos #21. com.apple.root.default-qos #22. org.AsyncDisplayKit.ASDisplayLayer.displayQueue #23. Thread #24. Thread #25. Thread #26. Thread #27. Thread #28. PINRemoteImageManager Concurrent Operation Queue :: NSOperation 0x1706506e0 (QOS: UTILITY) |
|
From @appleguy on February 3, 2017 23:50 Is this crash log from iOS 8 by chance? Which iOS version?
|
|
From @dssheng on February 15, 2017 8:3 Here is a log, ASDK 2.0.1 Incident Identifier: BD1E6BF8-82EE-4A67-815B-AA0FAE953885 Date/Time: 2017-02-10 02:03:01.3995 +0800 Exception Type: EXC_CRASH (SIGABRT) Thread 0 name: Thread 1 name: Thread 2: Thread 3 name: Thread 4 name: Thread 5 name: Thread 6 name: Thread 7 name: Thread 8 name: Thread 9 name: Thread 10 name: Thread 11 name: Thread 12 name: Thread 13 name: Thread 14 name: Thread 15 name: Thread 16 name: Thread 17 name: Thread 18: Thread 19 name: Thread 20 name: Thread 21 name: Thread 22 name: Thread 23: Thread 24: Thread 25: Thread 26: Thread 22 crashed with ARM Thread State (64-bit): Binary Images: EOF |
|
From @yxztj on March 10, 2017 1:59 Same issue here. 0 |
|
From @yxztj on March 20, 2017 2:6 Devices are all iOS10 |
|
From @3a4oT on March 24, 2017 15:39 All iOS 10.x, ~1k crashes per day (all unique), 100% not in focus (per Fabric). Crashed: com.apple.main-thread |
|
Happens iOS 9 as well. Always happens when app is in background |
|
Clue: |
|
We just moved to Texture and this is our top crash right now. Attached some stats which might be helpful. |
|
@thekirankumar Thanks for the screenshot - what is weird about that crash is that the stack does not seem possible. In other words, it could be memory corruption or some other symbolication failure leading to that issue. Could you share the entire stack, ideally of all backtraces? Attaching the .txt log that Crashlytics provides would be a good way to go. Also, let us know what version of Texture you're on - either pod version number or commit hash. A few releases ago, there were some actual causes for a ~Mutex() failure, but I'm not familiar with any known unsolved ones (which again, could make this report important). |
|
@appleguy Attached text file from fabric. |
|
@kushalsharma Thanks for sharing the full log. I took a pretty close look at all of the threads -- the stack on main is definitely very strange. Are you by chance using ASDisplayNodes inside the .contentView of a UIAlert or something else similar? I can't figure out why exit is called from the UIAlertManager. I would love to make progress on this, but it's pretty hard to tell what the connection is between UIAlert (which is not used anywhere in Texture) and the Texture framework is. I think this requires more information based on knowledge of your app. |
|
@appleguy here is last crash log from our Fabric topCrash.txt. Texture 2.3.3. Integrated since AsyncDisplayKit 2.0.2 and crash was there. Do u need any extra info? |
|
@appleguy Here is some info from my side - http://crashes.to/s/a1949a0925a / http://crashes.to/s/7d0c464960f / http://crashes.to/s/e43ab8f7d5c :) EDIT: We are not using async display kit for alerts or anything like that - just for table view controllers with cell nodes. |
|
Can somebody confirm issue still occur on Texture 2.3.4? |
|
I have same issue on Texture 2.3.4.
I'm sure that this problem is related to the mixture of the Texture component and the native component. In my project there is a ASTableNode of like this, For some reason I use UIImageView in ASCellNode
If the list is very violent fast scrolling, the above error will occur, I also use Batch Fetching API in ASTableNode. But when i replaced UIImageView to ASNetworkImageNode this error this error has not happened. I'll upload a demo later, if it goes well. |
|
@bawn thanks. Interesting info. In my case parent view is I can't repro it locally=( |
|
@3a4oT |
|
Here is code which overlaps with native components. // Table node size when offile banner triger UI changes
RACSignal *frameSignal = RACObserve(self, tableView.bounds);
@weakify(self);
[[frameSignal deliverOnMainThread] subscribeNext:^(id _Nullable x) {
@strongify(self);
self.tableNode.frame = self.tableView.frame;
[self.view layoutSubviews];
}]; |
|
Same problem here, with Texture 2.3.2. We have a ASTableNode with cells, no Alerts involved whatsoever: @appleguy Here is the full trace, in case it helps: ASDN-Mutex-crash.txt |
|
@cesteban hey! What do u use for parent container? In my case, I use just plain |
|
We have a |
|
same issue: Texture Version:2.4 Crash Stack: ASThread.h line 204 is: |
|
So after we have switched to Texture 2.4 and wrap |
|
Can confirm that #577 fixed it. thanx @nguyenhuy |
From @dssheng on August 1, 2016 12:17
Crash at here.
using AsyncDisplayKit ~ 1.9.80
ASThread.h
line 117
Copied from original issue: facebookarchive/AsyncDisplayKit#2017
The text was updated successfully, but these errors were encountered: