Skip to content
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

Closed
chris-feist opened this issue Jan 24, 2020 · 17 comments
Closed

iOS Native Crash when uploading blobs using aws-sdk #27857

chris-feist opened this issue Jan 24, 2020 · 17 comments
Labels
Bug Platform: iOS iOS applications.

Comments

@chris-feist
Copy link

chris-feist commented Jan 24, 2020

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: @satya164

React 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

  1. I have created an Expo snack with a repro case: https://snack.expo.io/@chris-feist/document-upload-issue-demo
  2. Select file and upload it using the aws-sdk and S3 client.
  3. Note that it does not repro when the device/emulator is connected to the RN debugger

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

@react-native-bot react-native-bot added the Platform: iOS iOS applications. label Jan 24, 2020
@seavan
Copy link

seavan commented Jan 27, 2020

I am experiencing a similar problem with tus blob uploads:

2020-01-27 23:58:14.194 [fatal][tid:com.facebook.react.NetworkingQueue] Exception '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]'  was thrown while invoking sendRequest on target Networking with params (
        {
        data =         {
            blob =             {
                "__collector" =                 {
                };
                blobId = "24227DB3-8B03-43E6-A922-8E3A7CB11A6D";
                offset = 5242880;
                size = 1933153;
            };
            trackingName = unknown;
        };
        headers =         {
            "content-type" = "application/offset+octet-stream";
            cookie = "Vibe-Session-Id=9a7m28ofzh1c:LEfiEog13h0D-9bQEdWcY7N7pMh5SOm8CwQOdaPLDJ8=";
            "tus-resumable" = "1.0.0";
            "upload-offset" = 5242880;
        };
        incrementalUpdates = 0;
        method = PATCH;
        responseType = text;
        timeout = 0;
        url = "https://gw-dev.vibetech.org/upload/f21a583708fdd7db65c9993fd804b5e0+tbh6onBy0Vx47WofKC5XON9pRl.g9kEHEN7k06Czp5yJw15TrQKicqO4IBxRffeKmz3aodrWYX7OrvRrY5qJ9kPrU6lj0fLovRFXrU3xudUJMOH2lQl_c2Ts8x4jHNAo";
        withCredentials = 0;
    },
    1447
)
callstack: (
	0   CoreFoundation                      0x00000001c0f72a5c 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 1227356
	1   libobjc.A.dylib                     0x00000001c0c99fa4 objc_exception_throw + 56
	2   CoreFoundation                      0x00000001c0fc8360 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 1577824
	3   CoreFoundation                      0x00000001c0fd16b4 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 1615540
	4   CoreFoundation                      0x00000001c0e5f73c 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 100156
	5   CoreFoundation                      0x00000001c0e515d0 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 42448
	6   Vibe User                           0x0000000104528d20 -[RCTBlobManager handleNetworkingRequest:] + 664
	7   Vibe User                           0x0000000104540aa4 -[RCTNetworking processDataForHTTPQuery:callback:] + 1336
	8   Vibe User                           0x000000010453fa7c -[RCTNetworking buildRequest:completionBlock:] + 3052
	9   Vibe User                           0x0000000104545890 -[RCTNetworking sendRequest:responseSender:] + 236
	10  CoreFoundation                      0x00000001c0f78c20 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 1252384
	11  CoreFoundation                      0x00000001c0e48d30 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 7472
	12  CoreFoundation                      0x00000001c0e49908 1B9B1E61-8CB4-3903-9870-402C3DE959BB + 10504
	13  Vibe User                           0x000000010445aaf8 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 1896
	14  Vibe User                           0x000000010445e4f4 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 660
	15  Vibe User                           0x000000010445e068 _ZZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEiENK3$_0clEv + 144
	16  Vibe User                           0x000000010445dfcc ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 28
	17  libdispatch.dylib                   0x00000001068c57fc _dispatch_call_block_and_release + 24
	18  libdispatch.dylib                   0x00000001068c6bd8 _dispatch_client_callout + 16
	19  libdispatch.dylib                   0x00000001068cdb48 _dispatch_lane_serial_drain + 744
	20  libdispatch.dylib                   0x00000001068ce6e4 _dispatch_lane_invoke + 448
	21  libdispatch.dylib                   0x00000001068d9adc _dispatch_workloop_worker_thread + 1324
	22  libsystem_pthread.dylib             0x00000001c0c8eb88 _pthread_wqthread + 276
	23  libsystem_pthread.dylib             0x00000001c0c91760 start_wqthread + 8
)

@thekrol01
Copy link

thekrol01 commented Mar 26, 2020

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.

@thekrol01
Copy link

thekrol01 commented Apr 1, 2020

Any workarounds?

@chris-feist
Copy link
Author

chris-feist commented Apr 1, 2020

Any workarounds?

Yes, in your node_modules comment out the 3 lines here

//  if (offset != 0 || (size != -1 && size != data.length)) {
//    data = [data subdataWithRange:NSMakeRange(offset, size)];
//  }

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

@thekrol01
Copy link

thekrol01 commented Apr 1, 2020

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?
Did you also clean cache etc in Xcode before you ran a new build?

@ZhangTaoK
Copy link

ExceptionsManager.js:126 Exception '-[__NSDictionaryM substringToIndex:]: unrecognized selector sent to instance 0x600002a46a60' was thrown while invoking sendRequest on target Networking with params (
{
data = {
formData = (
{
fieldName = file;
headers = {
"content-disposition" = "form-data; name="file"; filename="image.png"";
"content-type" = "multipart/form-data";
};
name = "image.png";
type = "multipart/form-data";
uri = {
image = "/Users/abysskitty/Library/Developer/CoreSimulator/Devices/8B0E5610-1E9F-429C-BED7-F52D0DC70236/data/Containers/Data/Application/BEAEDC11-43DB-466C-ADE2-41AD8066B910/tmp/react-native-image-crop-picker/C57F0BB5-0844-4D22-BCA5-C7F7EAB06E99.jpg";
};
}
);
trackingName = unknown;
};
headers = {
"content-type" = "multipart/form-data";
};
incrementalUpdates = 0;
method = POST;
responseType = blob;
timeout = 0;
url = "http://enter.teach.zhangjiwei.top/api/upload/upload";
withCredentials = 1;
},
5333
)

@stale
Copy link

stale bot commented Jul 4, 2020

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.

@stale stale bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Jul 4, 2020
@seavan
Copy link

seavan commented Jul 4, 2020

still present in react-native 0.61.5

@stale stale bot removed the Stale There has been a lack of activity on this issue and it may be closed soon. label Jul 4, 2020
@stale
Copy link

stale bot commented Oct 4, 2020

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.

@stale stale bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Oct 4, 2020
@georgiosd
Copy link

Certainly not fixed

@stale stale bot removed the Stale There has been a lack of activity on this issue and it may be closed soon. label Oct 4, 2020
@dlbears
Copy link

dlbears commented Apr 6, 2021

Same issue (particularly noticeable on older ios devices when using large files, 6S)

@Arnoldnuo
Copy link

Same issue on iPhone 7 Plus, iOS 15.1 .

@samal-rasmussen
Copy link

samal-rasmussen commented Mar 10, 2022

Experienced the same error and can confirm that the fix here works: #31392

@marquinmpfs
Copy link

Same issue on all Iphones

image

Any solution?

@marquinmpfs
Copy link

here

I tried to do it the way you did, but here it also didn't work I made the patch.

image

image

@wheelie33
Copy link

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?

@maneesht
Copy link

maneesht commented Nov 4, 2022

It seems like there are multiple problems here, as applying the fix from #31392 doesn't quite work for me. As mentioned here, there seems to be a race condition between adding to the blob and sending it out.

kelset pushed a commit that referenced this issue Mar 28, 2023
)

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
kelset pushed a commit that referenced this issue Apr 3, 2023
)

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
kelset pushed a commit that referenced this issue Apr 3, 2023
)

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
OlimpiaZurek pushed a commit to OlimpiaZurek/react-native that referenced this issue May 22, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Platform: iOS iOS applications.
Projects
None yet
Development

Successfully merging a pull request may close this issue.