iOS Memory Leak when KTOR Get Request is Made

[Tony-T-R-A-N]

Hello, I am having an issue with iOS memory leaks when I make a ktor get request.
The dispatcher is being built on the iosX64/iosArm32/iosArm32 side through an class implementing CoroutineDispatcher() with the override fun dispatch doing

dispatch_async(dispatch_get_main_queue()) {
    block.run()
}

class DummyClass() : CoroutineScope {
​
	override val coroutineContext: CoroutineContext
        get() = dispatcher
	
	fun execute(suspendFunc: suspend () -> Unit) {
		launch { suspendFunc() }
	}    
​
	fun request(
		parameter: String,
		callback: (MyResponse?, Throwable?) -> Unit
	) {
		execute {
			try {
				val result = httpClient.get<MyResponse> {
					url("PUT A URL HERE")
				}
​
				callback(result, null)
			} catch (e: Throwable) {
				callback(null, e)
			} finally {
				executor.cancel()
			}
		}
	}
	
}

[bherbst]

I spent some time over the last few days digging into this issue, and believe I have found the issue (and solved it).

Background

We made a sample app that simply makes 300 API calls in quick succession in order to (roughly) test Ktor's performance and memory profile.

As it stands today (with Ktor 1.3.0-beta-2), the memory profile looks something like this, with the peak of the graph being roughly 122MB:

Looking at what is leaking, it appears as though the biggest source is a large number of 96KB mallocs in SSLBuffer, which are tracked on the green graph above. Here's a breakdown of some of those allocations and a stack trace:

After looking through the call traces for these allocations, it appears as though the entire coroutine used for making the request was leaked, and these objects just happened to be the biggest single object connected to that leak.

The fix

Ktor's iOS client engine currently opens an NSUrlSession using sessionWithConfiguration(), which carries this warning for the delegate parameter:

Important

The session object keeps a strong reference to the delegate until your app exits or explicitly invalidates the session. If you do not invalidate the session by calling the invalidateAndCancel or finishTasksAndInvalidate method, your app leaks memory until it exits.

After forking IosClientEngine and adding a call to finishTasksAndInvalidate() at the end, the leak appears to be fixed and the memory consumption graph looks like this (again, the 96KB SSLBuffer allocations are shown in the green graph):

These allocations appear to be properly collected now, and no longer leak.

PR #1480 contains this fix.

[e5l]

Fixed in master