[iOS] Crash in [RCTModuleData setUpMethodQueue] #9334
Comments
|
We are seeing this same crash in our reporting tool. It is currently the top crash in our application. We have not been able to figure out how to reproduce it but an interesting thing in the log is |
|
@Damir46 what version of react native are you on? |
|
For us, this crash occurs in the context of the RCTImageLoader. And it has the same API MISUSE: Resurrection of an object message. This is on React-Native .30. Here is the stack trace: Crashed: com.facebook.react.ImageLoaderURLCacheQueue |
|
@basketofsoftkittens We are on 0.28.0 |
|
I met the same crash. |
ghost
changed the title
|
It's also the top crash of our application and we can't figure out what's the problem without being able to reproduce the issue. We keep looking into it and share our findings here. Crash: [RCTModuleData setUpMethodQueue] (RCTModuleData.m:186) @nicklockwood, @javache, @tadeuzagallo any idea what could be the reason for this crash? |
|
I have the same PB from my users, I do not know where this crash occurs unfortunatly. React native 0.31 Crashed: com.facebook.react.ImageLoaderURLCacheQueue |
|
Our theory behind this is that there are several places where weak refs are being treated like strong refs. And also a series of places where things were not being null-checked. We are in the process of testing a patch: Curse@bdf1354 Apply at your own risk, obviously. |
|
@conover it really looks like it's losing the referencing at some point, you're right. The patch looks promising. Could you please share your findings as soon as you've evaluated the crash rate with your patch? We'll probably make our own patch with detailed debug tracking as well. @ymmuse we're also seeing quite some RCTImageLoader crashes (5 variations) in our crash reporting tool, but by far not as many as the setUpMethodQueue crash. Here's some additional information that might be useful:
I've also created a GitHub project providing the abstract structure of our React Native integration, might be of use when investigating possible issues: |
|
So the RCTImageLoader crashes persist despite hardier In current testing, it seems like this block is the culprit: return ^{
if (cancelLoad) {
cancelLoad();
cancelLoad = nil;
}
OSAtomicOr32Barrier(1, &cancelled);
};This is in
The call stack flows from The following lines will throw an EXC_BAD_ACCESS exception:
This is reproducible, but not pinned down to an exact set of steps that will make it crash guaranteed. We have a ListView with a large number of rows in which a Ideas: Setting a property to nil that has already been dereferenced, will cause an EXC_BAD_ACCESS exception. Obviously this property is being released, but where and why that can happen is still unclear. My current idea is that the app is experiencing memory pressure and pruning views, which are still loading and holding references to the callback blocks, and then the app crashes doing what it thinks it should do. I'm not sure who to ping on this, but I'm going to ping @brentvatne since he seems to be all over the place in the issues here. Sorry if this is not your area Brent, but maybe you could point us in the right direction here? |
|
@javache is the man for this one, I believe |
|
what's the status on this? |
|
Starting to feel the pain of using RN in production from this. I have the time to go digging but some pointers would be great - @javache? Thanks! |
|
We were loading a react view when the application launched that was not on the current tab. We were doing this so that when the user navigated to that tab the view was already built. We removed this and this crash went way down. Haven't had time to dig much into it but maybe it will help some other people who are seeing it in high numbers. |
|
We are testing some block changes, and will update with results from the newest build. We are transitioning the code that looks like this: return ^{
if (cancelLoad) {
cancelLoad();
cancelLoad = nil;
}
OSAtomicOr32Barrier(1, &cancelled);
};to this: return ^{
dispatch_block_t innerCancel = [cancelLoad copy];
if (innerCancel) {
innerCancel();
innerCancel = nil;
}
OSAtomicOr32Barrier(1, &cancelled);
};Doing this seems to fix it while testing, but this is really a huge problem in memory starved cases that are harder to debug and test in house. We really only started seeing these crashes once the app was out in production and crash reports started arriving in droves. |
|
My use case made it very easy to reproduce - this change fixes it thanks @bennyguitar !!! |
|
This line still causes me the issue even after @bennyguitar's change |
|
@bennyguitar We are seeing this crash disappear at FB with the latest version of React Native. Your patch can cause the scenario where items are cancelled multiple times, since cancelLoad is never nilled out. |
|
@javache 0.33 or 0.34 release candidate? EDIT: my code changes were for 0.33 because it was crashing for our use case. I haven't tried with 0.34 yet. |
|
This would be v34. |
|
Okay thanks, when I get a chance to update I'll do it and test again to verify that it's fixed. |
|
@javache thanks for the great news, I'll update to the 0.34 stable version asap and release a new app version in the following week(s). I will monitor our crashes, if there are any, and let you know if I can verify the fix. |
|
@javache still seeing this crash in 0.34. Stack Trace: View Set Up Basically we have a EDIT: Forgot to mention that this happens when setting |
|
@bennyguitar did you solve this problem? |
|
@Griffosx: I did not, though the crashes are more infrequent with the 0.34 code changes. |
|
I'm seeing the same thing, reproduction while scrolling through a long social feed now takes ~20 seconds to crash rather than 5 seconds. |
|
So, the crash not still fixed with the 0.34? |
|
@ymmuse no it's not |
|
We're seeing the same crash on 0.33 in high numbers, we're going to update to 0.34.1 and update here. |
|
@facebook-github-bot label iOS |
facebook-github-bot
added
Platform: iOS
|
The issue is not resolved in 0.34.1 Workoround Note: |
|
@Griffosx I believe you're seeing this "work" because technically the image has already been downloaded at that point. There's a It looks like there have been two commits to master that potentially deal with this problem. The first one is slated for The first fix "sounds" like it's correct via the commit description and reasoning. I'm going to add these two commit changes to our current fork and see if we can get the app to crash or not. |
|
I also found this crash. it's error image url in listview.can you fix listview memory. |
|
I can also confirm that this is still crashing, even though the crash rate got much better after upgrading to version 0.36.0.rc.1. We upgraded our production app from 0.28.0 to 0.34.0 two weeks ago. After that, we experienced an enormous increase of crashes, so we decided to release a new app update with 0.36.rc.1 as soon as possible (hence the release candidate and not the stable version) as there were two promising commits in 0.35.0. and 0.36.0,rc.1. After evaluating the crash rate of this crash after a week on production, the crash rate was reduced by 88%, so it really helped a lot. But still, a proper fix would be amazing. |
|
also crash in 0.37.0 |
|
We're no longer seeing this crash internally. |
I'm looking for a squashing bug in an iOS app that I can't work out/reproduce. I am getting a logged error of
Selector name found in current argument registers: retainThis only seems to happen on iOS devices with 9.3
(Currently one of our top crashes in our application)
Log file for crash:
The text was updated successfully, but these errors were encountered: