Memory leaks inside FirebasePerformance InstrumentSessionWithConfiguration

[khaptonstall]

[REQUIRED] Step 1: Describe your environment

• Xcode version: 12.5
• Firebase SDK version: 8.1.1
• Installation method: CocoaPods
• Firebase Component: Analytics, Crashlytics, RemoteConfig, Core, Performance

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

What happened? How can we make the problem occur?
We're seeing memory leaks on startup seemingly stemming from FirebasePerformance. On startup, we're calling FirebaseApp.configure(withOptions:) inside func application(_:didFinishLaunchingWithOptions:), followed by a call to initialize another third-party SDK, Optimizely. (That's where the DefaultDataFileHandler.swift in the screenshot below comes from.)

Upon editing our Podfile to remove the Performance subspec, another run via Instruments shows no leaks occur.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[khaptonstall]

Just digging a bit further here, this is the getSession method from the stack trace in my screenshot:

    open func getSession(resourceTimeoutInterval: Double?) -> URLSession {
        let config = URLSessionConfiguration.ephemeral
        if let resourceTimeoutInterval = resourceTimeoutInterval,
            resourceTimeoutInterval > 0 {
            config.timeoutIntervalForResource = TimeInterval(resourceTimeoutInterval)
        }
        return URLSession(configuration: config)
    }

If I just grab the URLSession initialization code and manually trigger it in my application (e.x. by tapping a button), I'll again see the same FirebasePerformance method triggering a memory leak in instruments:

_ = URLSession(configuration: URLSessionConfiguration.ephemeral)

[maksymmalyhin]

@khaptonstall Thank you for reporting the issue.

I could not reproduce the memory leak with a quickstart app. It looks like some code in your app or the project setup may be a precondition for the memory leak.

We need more information to make progress on the issue. Could you please provide us a sample app where the leak is reproducible to debug? Alternatively I would recommend trying to get more information on the root cause of the leak with the profiler or by inspecting the Memory Graph after the request.

[khaptonstall]

@maksymmalyhin Thanks for the reply. I've created a simple demo application replicating the issue upon tapping the button on screen when the app loads. (You'll just need to add your own GoogleService-Info.plist file. Let me know if you need any specific settings from our application's plist to debug.)

FirebaseLeakDemo.zip

Here's Instruments after tapping the button:

Here's the Memory Graph after tapping the button:

[maksymmalyhin]

Thank you for the provided details! I can see the memory leak. We will keep investigation possible reasons and fixes. In the meanwhile you may temporary disable instrumentation with Performance.sharedInstance().isInstrumentationEnabled = false which disables problematic Firebase Performance logic.

[maksymmalyhin]

The reason of the issue I can see so far:

• Firebase Performance swizzles URLSession init to set a delegate proxy to be able to get metrics about the requests
• According to the docs if the delegate is configured for a URLSession instance then either invalidateAndCancel or finishTasksAndInvalidate method must be called to prevent memory leaks
• currently Firebase Performance doesn't call either of these methods

@khaptonstall You can workaround the issue on your end by calling finishTasksAndInvalidate method on your disposable URLSession instance after scheduling last request intended to run on this session. In this case you will be able to benefit from metrics collected by Firebase Performance without memory leaks.

[maksymmalyhin]

@visumickey Could you please investigate possible Firebase Performance fixes or consider documentation/logs updates to warn about the required session invalidation.

[khaptonstall]

Thanks @maksymmalyhin, that helps me better understand what's going on under-the-hood. I'd still like to see some way of fixing this on Firebase's end. As I reported in my original issue description the source of the URLSession is located in a third-party framework and out of our control. While a PR could be submitted on that third-party repo to call one of the invalidate methods, I don't think it's a reasonable expectation that all third-party frameworks utilizing URLSession should be calling the invalidate methods when they themselves aren't setting up delegates on the session.