I've been trying to figure out for the past two days why this simple setting up of a AWSS3 configuration could possibly create 5000+ memory leaks. This is the the code I have running in AppDelegate:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
// SetUp AWS Config
let myIdentityPoolId = Constants.AWS_IDENTITY_POOL_ID
let credentialsProvider: AWSCognitoCredentialsProvider = AWSCognitoCredentialsProvider(regionType: .USWest2,
identityPoolId: myIdentityPoolId)
if let configuration = AWSServiceConfiguration(region: .USWest2, credentialsProvider:credentialsProvider) {
AWSS3.register(with: configuration, forKey: "defaultKey")
}
return AWSMobileClient.sharedInstance().interceptApplication(application,
didFinishLaunchingWithOptions: launchOptions)
}
Using Instruments, I've tested removing all the code I shared (except for the return AWSMobileClient.sharedInstance().interceptApplication) and found that I get no memory leaks, but as soon as I add it back I end up with all the leaks... What gives?
If it helps, I'm wanting to list the objects of my AWS bucket which works with the following code:
let listRequest: AWSS3ListObjectsRequest = AWSS3ListObjectsRequest()
let s3 = AWSS3.s3(forKey: "defaultKey")
listRequest.bucket = Constants.AWS_BUCKET
listRequest.prefix = Constants.SPECIAL_PREFIX
s3.listObjects(listRequest).continueWith { (task) -> AnyObject? in
}
Am I making an obvious mistakes?
Memory leaks occur when an application allocates memory for an object, but then fails to release the memory when the object is no longer being used. Over time, leaked memory accumulates and results in poor app performance and even crashes.
The Memory Profiler is a component in the Android Profiler that helps you identify memory leaks and memory churn that can lead to stutter, freezes, and even app crashes. It shows a realtime graph of your app's memory use and lets you capture a heap dump, force garbage collections, and track memory allocations.
Causes of Memory Leaks and Their Solutions One should not use static views while developing the application, as static views are never destroyed. One should never use the Context as static, because that context will be available through the life of the application, and will not be restricted to the particular activity.
If your app can work with these leaks then you can just file a bug here and wait for the fixes.
It seems they are inheriting these leaks since long time as you can see here and here. This issue S3 multipart upload memory leak is still open and marked as a bug so you need to wait until these are fixed.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With