-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS Native Crash when uploading blobs using aws-sdk #27857
Comments
I am experiencing a similar problem with tus blob uploads:
|
I am experiencing the same problem on IOS with the aws-sdk ( "aws-amplify": "^2.2.7",)/ after installing react native 0.61.5 on a physical device with Testflight. Same code works fine with RN 0.61.4. The crash happens randomly after every one or two PUT uploads. I have also tested with commenting out the suggested line: https://github.com/facebook/react-native/blob/v0.61.5/Libraries/Blob/RCTBlobManager.mm#L101. But i my case the crash still occurs randomly after a couple of PUT uploads. Same code on Android works fine. |
Any workarounds? |
Yes, in your
Then use something like patch-package Edit: Looks like you said you tried that. I have been using this workaround for 2 months without issues |
Thank you for the reply. Perhaps I am doing something wrong. I only commented out the lines in node_modules. Do I have to patch the module to make it work? Perhaps you have more details on how to do this? |
ExceptionsManager.js:126 Exception '-[__NSDictionaryM substringToIndex:]: unrecognized selector sent to instance 0x600002a46a60' was thrown while invoking sendRequest on target Networking with params ( |
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions. |
still present in react-native 0.61.5 |
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions. |
Certainly not fixed |
Same issue (particularly noticeable on older ios devices when using large files, 6S) |
Same issue on iPhone 7 Plus, iOS 15.1 . |
Experienced the same error and can confirm that the fix here works: #31392 |
This still errors out. EVERY Work around (and I use that term loosely) is not working. There are NO official guides to this. Can ANYONE that knows the solution share it? |
) Summary: This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided. https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123 When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated. https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25 Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd. Fixes #29970 Fixes #27857 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Blob data is no longer prematurely deallocated when using blob.slice Pull Request resolved: #31392 Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there. Reviewed By: javache Differential Revision: D41730782 Pulled By: cortinico fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
) Summary: This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided. https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123 When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated. https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25 Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd. Fixes #29970 Fixes #27857 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Blob data is no longer prematurely deallocated when using blob.slice Pull Request resolved: #31392 Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there. Reviewed By: javache Differential Revision: D41730782 Pulled By: cortinico fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
) Summary: This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided. https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123 When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated. https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25 Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd. Fixes #29970 Fixes #27857 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Blob data is no longer prematurely deallocated when using blob.slice Pull Request resolved: #31392 Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there. Reviewed By: javache Differential Revision: D41730782 Pulled By: cortinico fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
…ebook#31392) Summary: This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided. https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123 When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated. https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25 Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd. Fixes facebook#29970 Fixes facebook#27857 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Blob data is no longer prematurely deallocated when using blob.slice Pull Request resolved: facebook#31392 Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there. Reviewed By: javache Differential Revision: D41730782 Pulled By: cortinico fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
When using the
aws-sdk
package on iOS to upload files to S3, iOS experiences a native crash. I have narrowed it down to this line here: https://github.com/facebook/react-native/blob/v0.61.5/Libraries/Blob/RCTBlobManager.mm#L101. If I comment out that line, then the upload works fine. I am not an iOS expert, so I am not sure what it is doing. Maybe the original author can comment: @satya164React Native version: 0.61.5
Error
Exception '*** -[NSConcreteMutableData subdataWithRange:]: range {0, 1769328} exceeds data length 458' was thrown while invoking sendRequest on target Networking with params (
{
data = {
blob = {
"__collector" = {
};
blobId = "11f8ea23-de9a-4a08-ad4d-c4181df42883";
offset = 0;
size = 1769328;
};
trackingName = unknown;
};
headers = {
authorization = "AWS4-HMAC-SHA256 Credential=ASIA6QAAAAAHOZSVFSMH/20200123/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-meta-document-type;x-amz-meta-file-id;x-amz-meta-file-name;x-amz-meta-person-id;x-amz-security-token;x-amz-user-agent, Signature=cee1e24a313d918991150c4e9864ef8cea2f0756cd148b83307155006755d45a";
"content-type" = "application/octet-stream";
"x-amz-content-sha256" = "UNSIGNED-PAYLOAD";
"x-amz-date" = 20200123T195414Z;
"x-amz-security-token" = "FwoGZXIvYXdzEMX.....QcPwuX645EoVpgYfWkcuu63fH2Eyjhc9/zJBBiDfR2xroIZawDJxj2g0ur2IRZbBlS0d7sjcOW3LbVQ+bbEIv9PuffwSLn87JVIFkKObzp/EFMi3k+pjO0XGMKyzbHQmOERlegrv7PvKiITp6K6uFJktcQ4oewkuMsaF2CzBQ9xQ=";
"x-amz-user-agent" = "aws-sdk-js-react-native/2.608.0 callback";
};
incrementalUpdates = 1;
method = PUT;
responseType = base64;
timeout = 120000;
url = "https://public-bucket.s3.amazonaws.com/my-upload-file.pdf";
withCredentials = 1;
},
7255
)
callstack: (
0 CoreFoundation 0x000000010b19a27e _exceptionPreprocess + 350
1 libobjc.A.dylib 0x0000000109e38b20 objc_exception_throw + 48
2 Foundation 0x0000000107f8ce40 -[NSData(NSData) writeToFile:options:error:] + 0
3 MyApp 0x00000001066e5ae8 -[RCTBlobManager resolve:offset:size:] + 472
4 MyApp 0x00000001066e57c2 -[RCTBlobManager resolve:] + 706
5 MyApp 0x00000001066e8992 -[RCTBlobManager handleNetworkingRequest:] + 626
6 MyApp 0x0000000106701fa5 -[RCTNetworking processDataForHTTPQuery:callback:] + 1749
7 MyApp 0x0000000106700c35 -[RCTNetworking buildRequest:completionBlock:] + 3749
8 MyApp 0x0000000106707e4d -[RCTNetworking sendRequest:responseSender:] + 253
9 CoreFoundation 0x000000010b1a120c invoking + 140
10 CoreFoundation 0x000000010b19e3af -[NSInvocation invoke] + 319
11 CoreFoundation 0x000000010b19e684 -[NSInvocation invokeWithTarget:] + 68
12 MyApp 0x0000000106612c12 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 2658
13 MyApp 0x0000000106616d47 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 791
14 MyApp 0x0000000106616853 _ZZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEiENK3$_0clEv + 131
15 MyApp 0x00000001066167c9 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 25
16 libdispatch.dylib 0x000000010e3bc848 _dispatch_call_block_and_release + 12
17 libdispatch.dylib 0x000000010e3bd7b9 _dispatch_client_callout + 8
18 libdispatch.dylib 0x000000010e3c3526 _dispatch_lane_serial_drain + 707
19 libdispatch.dylib 0x000000010e3c3f5c _dispatch_lane_invoke + 388
20 libdispatch.dylib 0x000000010e3cdff9 _dispatch_workloop_worker_thread + 626
21 libsystem_pthread.dylib 0x00007fff524636fc _pthread_wqthread + 290
22 libsystem_pthread.dylib 0x00007fff52462827 start_wqthread + 15
)
RCTFatal
facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&)
facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)::$_0::operator()() const
invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread
Steps To Reproduce
aws-sdk
andS3
client.Describe what you expected to happen:
I expect the upload to work (as it does on android).
Snack, code example, screenshot, or link to a repository:
https://snack.expo.io/@chris-feist/document-upload-issue-demo
The text was updated successfully, but these errors were encountered: