EXC_BAD_ACCESS in AWSS3 #2314
Comments
|
Any updates on this issue? We're on version 2.19.1, and we've been receiving reports of crashes that appear to be related to TransferUtility multipart uploads. We seem to receive more crash reports right after releasing a new version of the app. For months we weren't receiving any crash logs, but now that we've received a few, they all appear to be related to Until there is a fix, for now we've decided to avoid using multipart uploads for files < 5 GB. However, is there a way to clear all existing subtasks (ie. from the database)? We were hoping that doing so on startup might help to prevent the app from crashing. |
|
@diesal11 & @danieldekerlegand Thanks for reporting the issue and for the context. The implicated method ( |
palpatim
added
pending-community-response
|
@palpatim Thanks for getting back to me. After your question, we did a code review. In general, the TransferUtility instance should have only been created once upon app startup, but we did realize that if the app switched back and forth between nonmultipart uploads and multipart uploads, it could potentially create a second instance. I don't think that's necessary, so we've refactored the code some so that only once instance can ever be created, which is done at startup as follows: Do you think it's possible that the issue was due to having multiple instances, where one instance was attempting to rehydrate parts from the database that didn't "belong" to it? Ideally, because we aren't concerned with being able to resume an upload after the app has been force quit, we would like to try clearing the DB of parts on startup, so that we can hopefully avoid the crash. |
|
Creating the TU instance at startup (or once before you begin processing transfers) is the recommended way of managing TU. The NSURLSessions are bound to the Transfer Utility's key (in your case, the
That seems like the most likely scenario. If the two TU instances were registered with the same key value at the same time, then they would have been running through their Let me know if your refactor works to eliminate the crash. |
|
@palpatim We've refactored our code to make sure that only one TU instance per key can exist at a time, and we haven't been able to replicate any
Along with this stack trace, we were able to find a few other TransferUtility-related device logs during crashes encountered while starting uploads with lower available disk space, such as < 10 GB, which appeared to occur even after restarting the app: We're finding that we can fairly reliably reproduce crashing behaviors when attempting to upload a large file > 5 GB with available disk space of <= 20 GB, with crashes and failed uploads becoming more and more frequent as disk space decreases. |
|
My initial thought is that iOS is reaping temporary files to reclaim space, and the multipart files are being removed before they're uploaded. Since the system behavior isn't under our control, if my hypothesis is correct, the best option I can think of is to move multipart temp files into a non-Cache, non-Temporary app-specific directory like Documents/some/transferutility/path, that is also tagged to not be backed up to iCloud. The downside to that would be that if we have any catastrophic failures that prevent us from properly deleting/cleaning up orphaned files (e.g., crashes that corrupt the internal state of the database queue), those files would persist indefinitely since iOS wouldn't attempt to clean them up. We'll add this to our backlog to consider the best ways of handling this. |
palpatim
added
pending-triage
|
@palpatim Thanks, that makes sense and is along the lines of what I was anticipating. Let me know if you need any more information on reproducing the crash. |
royjit
added
bug
|
Further investigation: TU creates temporary files during upload here and the background session for upload also creates temporary files as per this Apple doc. This will put strain on the available memory on the OS. TU creates these temporary file when the upload task, we need to figure out a better way to do this logic. |
|
Adding to the list of items to check - See if a single instance of TU have any threading issue and the file write is working in a thread safe manner. |
* method has experienced crashes and uses low level POSIX API * uses higher level FileManager API with error checking * includes unit test for new implementation
|
@diesal11 The code for creating the partial file has been updated so that it is more reliable. It will be included in the next release. |
brennanMKE
added
closing soon
and removed
follow up
|
2.26.1 has been released https://github.com/aws-amplify/aws-sdk-ios/releases/tag/2.26.1 |
brennanMKE
removed
pending-release
|
@diesal11 Please let us know if you are not able to repro the crash with your code with this update. We can reopen the issue if the crash is still happening. The new code replaces the low level POSIX calls with higher level Objective-C methods which Apple supports along with the changes which have been made to the filesystem implementation. My expectation is that using NSFileHandle will behave better and if there is a problem the reason will be logged with |
…-amplify#3786) * fix(S3): rewrite create partial file function (aws-amplify#2314) * method has experienced crashes and uses low level POSIX API * now uses higher level FileManager API with error checking * includes unit test for new implementation
Describe the bug
We have seen a number of crashes from our error reporting that seem to be coming from the AWS SDK. As you will see in the attached stack trace a call to
fwritecontained within[AWSS3TransferUtility createTemporaryFileForPart]is causing aEXC_BAD_ACCESS/SIGBUScrash.Not sure what to do about this one but thought it was worth reporting. I don't believe we have set anything up incorrectly here but let me know if you require more context
To Reproduce
Unable to reproduce locally
Which AWS service(s) are affected?
AWSS3 SDK
Environment(please complete the following information):
Device Information (please complete the following information):
Additional context
Full stacktrace:
The text was updated successfully, but these errors were encountered: