KMM Memory Leak (RAM) issue

[ALXgba]

How frequently does the bug occur?

Always

Description

I have been using Java Realm in the past for an Android app, that I migrated recently to Kotlin Multiplatform in order to make it compatible with iOS. After testing, it appears that by running it in an iOS environment, my memory was getting saturated by a leak, which affected the RAM. So I made a really simple downgraded version of it which showcases what exactly fails in it. In short, by calling the realm.open and realm.close methods, I leak memory (instances of realm_scheduler according to my memory graph on Xcode, but anything related to realms seems to create a way too large amount of instances in it).

In short, my Swift code to be run on iOS only executes this, which creates a timer calling Leaker.leak() every .1s :

    var leaker = RealmLeaker()
    // Code skipped here for readability
        NavigationView {
            Text("A")
        }
        .onAppear() {
            var timer1 = Timer.scheduledTimer(withTimeInterval: 0.1, repeats: true) { timerI in
                // Leaking
                leaker.leak()
            }
        }

In the KMM side, here's the Leaker Class :

class RealmLeaker {
    fun leak() {
        val config = RealmConfiguration.Builder(setOf(TestClass::class))
            .build()

        // This should simply open, then close the realm. Note that if you comment everything below this, there is no leak.
        val realm: Realm = Realm.open(config)
        realm.close()
    }
}

And for more context, here's the "TestClass" that I use :

// This class isn't really useful. Only there to showcase the leak, its properties are outside the scope of the problem.
class TestClass : RealmObject{
    @PrimaryKey
    var _id : String = "0"

    var value : Boolean = false
    var key : String = "test"
}

Here’s a repo to reproduce the error : GitHub - ALXgba/realmKMMIssue: Memory leak using Kotlin API in a KMM project, when run in iOS environment. 1

This issue seemed to be previously patched, yet I can still reproduce it : #1463 (review)

Edit : While the issue doesn't seem so terrible using the Xcode debug graphs, the RAM used seems to grow at a small rate, but I have observed it in my actual app (not the test one) growing fast enough to crash after an hour or so as the whole RAM gets clogged up.

Can you reproduce the bug?

Always

Reproduction Steps

Open and close a realm instance from a KMM Project using Realm Kotlin SDK inside your Swift iOS project. Everytimes you do this, a memory leak occurs.

Version

1.11.0

Are you using encryption?

No

Platform OS and version(s)

iOS 16.6 | Android SDK 26 and up

[ALXgba]

I use the SDK locally, but I don't know how to change the tags of the ticket. Could someone please edit it?

[JustusBachmann]

Hi, i have the same problem in my kmm project. It seems that the realm-kotlin/releases branch provides a fix for this, is there any chance that the correction will be officially released soon? @clementetb

[clementetb]

Hi @JustusBachmann, we have addressed the issue here.

We have no planned release date yet, but you can use the snapshot builds. Please report back if the fix is working for you.

[ALXgba]

Hi @JustusBachmann, we have addressed the issue here.

We have no planned release date yet, but you can use the snapshot builds. Please report back if the fix is working for you.

Hello @clementetb. I have tried the snapshot on my test project, and I can confirm that it works. I hope it will come soon in an official release to integrate in my project. :)

[ALXgba]

Regarding the disk memory leak that I reported, that was an error on my part. Xcode was logging every read and writes to the disk in a file that wasn't cleaned, thus making it seem as if it was the database leaking. I will edit the issue's original description to reflect that.

[clementetb]

@ALXgba Ok, but the original issue was fixed as you stated in #1501 (comment)?

By the way, the fix is available in 1.12.0

[ALXgba]

@ALXgba Ok, but the original issue was fixed as you stated in #1501 (comment)?

Yes, the issue has been resolved in 1.12.0, and I have tested it.