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

chris-feist · 2020-01-24T19:08:02Z

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

I have created an Expo snack with a repro case: https://snack.expo.io/@chris-feist/document-upload-issue-demo
Select file and upload it using the aws-sdk and S3 client.
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

The text was updated successfully, but these errors were encountered:

seavan · 2020-01-27T23:16:58Z

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 · 2020-03-26T11:52:45Z

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 · 2020-04-01T07:41:05Z

Any workarounds?

chris-feist · 2020-04-01T14:37:30Z

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 · 2020-04-01T16:54:21Z

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 · 2020-04-05T07:03:51Z

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 · 2020-07-04T08:41:39Z

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.

seavan · 2020-07-04T21:01:30Z

still present in react-native 0.61.5

stale · 2020-10-04T02:35:07Z

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.

georgiosd · 2020-10-04T10:23:02Z

Certainly not fixed

dlbears · 2021-04-06T00:10:49Z

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

Arnoldnuo · 2022-01-19T03:22:18Z

Same issue on iPhone 7 Plus, iOS 15.1 .

samal-rasmussen · 2022-03-10T17:15:30Z

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

marquinmpfs · 2022-10-26T23:36:10Z

Same issue on all Iphones

Any solution?

marquinmpfs · 2022-10-27T01:32:45Z

here

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

wheelie33 · 2022-11-03T17:56:21Z

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 · 2022-11-04T23:28:59Z

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.

) 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  [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  [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

chris-feist added the Bug label Jan 24, 2020

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

thekrol01 mentioned this issue May 23, 2020

Native ios crash when uploading blob with aws amplify aws-amplify/amplify-js#5874

Closed

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

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 bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Oct 4, 2020

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

developius mentioned this issue Oct 15, 2020

Invalid JSON response decoding on iOS #30181

Closed

awinograd mentioned this issue Apr 20, 2021

Prevent native blob resource from being de-allocated prematurely #31392

Closed

rissois mentioned this issue Jun 25, 2022

uploadBytes to storage with expo Image picker causing app to crash with no logs firebase/firebase-js-sdk#5848

Open

facebook-github-bot closed this as completed in 36cc71a Dec 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

chris-feist commented Jan 24, 2020 •

edited

Loading

seavan commented Jan 27, 2020

thekrol01 commented Mar 26, 2020 •

edited

Loading

thekrol01 commented Apr 1, 2020 •

edited

Loading

chris-feist commented Apr 1, 2020 •

edited

Loading

thekrol01 commented Apr 1, 2020 •

edited

Loading

ZhangTaoK commented Apr 5, 2020

stale bot commented Jul 4, 2020

seavan commented Jul 4, 2020

stale bot commented Oct 4, 2020

georgiosd commented Oct 4, 2020

dlbears commented Apr 6, 2021

Arnoldnuo commented Jan 19, 2022

samal-rasmussen commented Mar 10, 2022 •

edited

Loading

marquinmpfs commented Oct 26, 2022

marquinmpfs commented Oct 27, 2022

wheelie33 commented Nov 3, 2022

maneesht commented Nov 4, 2022

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

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

Comments

chris-feist commented Jan 24, 2020 • edited Loading

Error

Steps To Reproduce

seavan commented Jan 27, 2020

thekrol01 commented Mar 26, 2020 • edited Loading

thekrol01 commented Apr 1, 2020 • edited Loading

chris-feist commented Apr 1, 2020 • edited Loading

thekrol01 commented Apr 1, 2020 • edited Loading

ZhangTaoK commented Apr 5, 2020

stale bot commented Jul 4, 2020

seavan commented Jul 4, 2020

stale bot commented Oct 4, 2020

georgiosd commented Oct 4, 2020

dlbears commented Apr 6, 2021

Arnoldnuo commented Jan 19, 2022

samal-rasmussen commented Mar 10, 2022 • edited Loading

marquinmpfs commented Oct 26, 2022

marquinmpfs commented Oct 27, 2022

wheelie33 commented Nov 3, 2022

maneesht commented Nov 4, 2022

chris-feist commented Jan 24, 2020 •

edited

Loading

thekrol01 commented Mar 26, 2020 •

edited

Loading

thekrol01 commented Apr 1, 2020 •

edited

Loading

chris-feist commented Apr 1, 2020 •

edited

Loading

thekrol01 commented Apr 1, 2020 •

edited

Loading

samal-rasmussen commented Mar 10, 2022 •

edited

Loading