SQLiteIndexManager grows in heap size without ever freeing memory

[griffenclark123]

[READ] Step 1: Are you in the right place?

Seeing indication of memory leak stemming from the SDK, not sure if there is guidance on usage on how to free up memory and looking for guidance there. If there is none than this should be investigated by the team.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Ladybug 2024.2.2 Patch 1
• Firebase Component: Firestore
• Component version: 25.1.3

[REQUIRED] Step 3: Describe the problem

We are seeing memory issues within our app where more and more heap space is taken up without memory being deallocated. After running long sessions with the application, I perform a heap dump of the app and use hprof-conv to convert it to a Java heap dump file and analyze it in Eclipse Memory Analyzer Tool (MAT). The common leak suspect that appears is SQLiteIndexManager, where a single instance occupies more and more heap space the longer the application is running. I've seen it take up to 17 MB of heap space alone in one instance.

Here is an example of what's reported in MAT on one of my recent heap dumps.

Steps to reproduce:

Not exactly sure what exact steps there are to reproduce. Our application is a bit unique such that it's intended to be used by multiple different users for their work (sharing a single device). In a given week, we could have up to 10 different users logging in and out of the app resulting in different user data we have to load from Firestore. We also need to have a long-running foreground service because the Android device is connected to a another device that provides engine data from a vehicle, so our application needs to be constantly monitoring this data and record events for regulation purposes. We're also heavily utilizing snapshot listeners to ensure our application can react to the latest data, from local updates or from server.

Mainly looking for insight into what could possibly be causing this, or if there is any guidance on how we can mitigate this. We try to instruct our users to ensure they turn off the devices when they are done using them such that we can restart our process with a clean heap, but there's still plenty of users who either forget or disregard that instruction.

Relevant Code:

These are the settings we are leveraging in our app

        val firestore = Firebase.firestore.apply {
            firestoreSettings = FirebaseFirestoreSettings.Builder()
                .setLocalCacheSettings(PersistentCacheSettings.newBuilder().setSizeBytes(CACHE_LIMIT_BYTES).build())
                .build()
            persistentCacheIndexManager?.apply {
                enableIndexAutoCreation()
            }
        }

CACHE_LIMIT_BYTES is set to 16 MB.

[tom-andersen]

This will require some work on our end. I found the place in code where memory is likely leaking:

firebase-android-sdk/firebase-firestore/src/main/java/com/google/firebase/firestore/local/SQLiteIndexManager.java

Lines 76 to 81 in fda3351

	/**
	* Maps from a target to its equivalent list of sub-targets. Each sub-target contains only one
	* term from the target's disjunctive normal form (DNF).
	*/
	// TODO(orquery): Find a way for the GC algorithm to remove the mapping once we remove a target.
	private final Map<Target, List<Target>> targetToDnfSubTargets = new HashMap<>();

I will bring it up with the team.