You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've tried for several weeks but it's hard to reproduce, but here're some of my thoughts:
When our client received a hot patch from server, we'll setup a new RCTBridge using new bundle, so the global shared bridge is pointing to the new bridge, and the old one will dealloc once there's no view holding it.
I'm not sure about the order of dealloc (destruction) of those modules and the method queue they're holding.
I noticed RCTImageLoader is actually using RCTNetworking module to load images, the callback of RCTNetworking is executed on its own method queue.
So when the RCTNetworkTask try to retain something from the queue of RCTImageLoader but actually it's been deallocated, it crashes.
Sorry but there's no special sample code to provide.
Solution
Is it possible to have a standalone global networking manager and image manager, instead of belonging to a bridge? Thus, when you have multiple bridges, or when you're deallocating one bridge, the networking queues are not deallocated, to prevent the crashes.
Also, although it's rare to have multiple RN bridges in one app, but sharing networking component may help on memory usage when you do have multiple bridges.
Btw, anyone knows if there's any fully tested, stable library to use AFNetworking as the networking layer of RN? I've found some node modules but seems it's already dead.
Additional Information
React Native version: 0.44.0
Platform: iOS
Development Operating System: macOS
Build tools: Xcode 8.3.3
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.
stalebot
added
the
Stale
There has been a lack of activity on this issue and it may be closed soon.
label
Jan 8, 2018
Description
We have several crashes from
RCTImageLoader
andRCTNetworkTask
, actually I think those fromRCTNetworkTask
are also those tasks fromRCTImageLoader
.Most of the stack trees may be useless, but those are the top ones:
Reproduction Steps
I've tried for several weeks but it's hard to reproduce, but here're some of my thoughts:
When our client received a hot patch from server, we'll setup a new
RCTBridge
using new bundle, so the global shared bridge is pointing to the new bridge, and the old one will dealloc once there's no view holding it.I'm not sure about the order of dealloc (destruction) of those modules and the method queue they're holding.
I noticed
RCTImageLoader
is actually usingRCTNetworking
module to load images, the callback ofRCTNetworking
is executed on its own method queue.So when the
RCTNetworkTask
try to retain something from the queue ofRCTImageLoader
but actually it's been deallocated, it crashes.I guess so because as you can see, one crash from
RCTImageLoader
happens on this line https://github.com/facebook/react-native/blob/v0.44.0/Libraries/Image/RCTImageLoader.m#L482 in threadcom.facebook.react.NetworkingQueue
.Sample Code
Sorry but there's no special sample code to provide.
Solution
Is it possible to have a standalone global networking manager and image manager, instead of belonging to a bridge? Thus, when you have multiple bridges, or when you're deallocating one bridge, the networking queues are not deallocated, to prevent the crashes.
Also, although it's rare to have multiple RN bridges in one app, but sharing networking component may help on memory usage when you do have multiple bridges.
Btw, anyone knows if there's any fully tested, stable library to use AFNetworking as the networking layer of RN? I've found some node modules but seems it's already dead.
Additional Information
The text was updated successfully, but these errors were encountered: