Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[KMP] Fix issue: memory leak found in Base58.decode in iOS #4031

Merged

Conversation

10gic
Copy link
Contributor

@10gic 10gic commented Sep 18, 2024

Description

Fix issue #4030

How to test

Run Rust, C++, Kotlin, Swift tests

Types of changes

Checklist

  • Create pull request as draft initially, unless its complete.
  • Add tests to cover changes as needed.
  • Update documentation as needed.
  • If there is a related Issue, mention it in the description.

If you're adding a new blockchain

  • I have read the guidelines for adding a new blockchain.

Screenshots

Before fixing, run Base58.decode 100000 times, it takes up to 200 MB of memory:
Xnip2024-09-18_15-25-56

After fixing, run Base58.decode 100000 times, it takes up to 97.4 MB of memory:
Xnip2024-09-18_15-21-17

Solution

The generated code before fixing:

package com.trustwallet.core

actual object Base58 {

    // ......

    actual fun decode(string: String): ByteArray? =
        TWBase58Decode(string.toTwString()).readTwBytes()         // toTwString and readTwBytes leak memory!


    // ......
}

Definition of old readTwBytes:

internal fun COpaquePointer?.readTwBytes(): ByteArray? =
    TWDataBytes(this)?.readBytes(TWDataSize(this).toInt())

The generated code after fixing:

package com.trustwallet.core

actual object Base58 {

    // ......

    actual fun decode(string: String): ByteArray? {
        val stringString = TWStringCreateWithUTF8Bytes(string)
        val result = TWBase58Decode(stringString).readTwBytes()
        TWStringDelete(stringString)
        return result
    }

    // ......
}

Definition of new readTwBytes:

internal fun COpaquePointer?.readTwBytes(): ByteArray? =
    this?.let {
        val result = TWDataBytes(it)?.readBytes(TWDataSize(it).toInt())
        TWDataDelete(it)
        result
    }

@10gic
Copy link
Contributor Author

10gic commented Sep 25, 2024

@satoshiotomakan Could you please review this PR?

@10gic 10gic force-pushed the fix-kmp-memory-leak-base58-decode branch from b94a2e0 to 355c345 Compare September 27, 2024 02:20
Copy link
Collaborator

@satoshiotomakan satoshiotomakan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work as usual! Could you please consider minor changes?

codegen/lib/templates/kotlin/ios_class.erb Show resolved Hide resolved
@satoshiotomakan
Copy link
Collaborator

@10gic can you please fix code formatting?
Screenshot 2024-09-30 at 11 50 04

The code will be available in the iOS Kotlin package, so it should be readable enough.

Please also note that iOS native bindings have been broken by changing val -> value function argument.
Could you please fix it?

@satoshiotomakan
Copy link
Collaborator

@10gic is it possible to revert val -> value argument name refactoring?

@10gic
Copy link
Contributor Author

10gic commented Sep 30, 2024

@10gic can you please fix code formatting? Screenshot 2024-09-30 at 11 50 04

The code will be available in the iOS Kotlin package, so it should be readable enough.

Please also note that iOS native bindings have been broken by changing val -> value function argument. Could you please fix it?

I noticed this issue. However, if I fix the too little code indentation in AnyAddress.kt, then Base58.kt will have too much indentation because the adjusted code in AnyAddress.kt is located within the actual companion object code block, which inherently requires more indentation.

@10gic
Copy link
Contributor Author

10gic commented Sep 30, 2024

@10gic is it possible to revert val -> value argument name refactoring?

Do you have any other considerations? Since the keywords in different languages are different, avoiding using them is the simplest way.

@satoshiotomakan
Copy link
Collaborator

The main reason is to avoid unnecessary breaking changes

@10gic is it possible to revert val -> value argument name refactoring?

Do you have any other considerations? Since the keywords in different languages are different, avoiding using them is the simplest way.

@10gic
Copy link
Contributor Author

10gic commented Sep 30, 2024

The main reason is to avoid unnecessary breaking changes

@10gic is it possible to revert val -> value argument name refactoring?

Do you have any other considerations? Since the keywords in different languages are different, avoiding using them is the simplest way.

Actually, I didn't intend to adjust this behavior in this PR. I can't remember what issue led me to change it. However, I can try to revert it.

@10gic
Copy link
Contributor Author

10gic commented Sep 30, 2024

@satoshiotomakan All comments have been resolved, please review again.

Copy link
Collaborator

@satoshiotomakan satoshiotomakan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@satoshiotomakan satoshiotomakan changed the base branch from master to dev October 1, 2024 09:05
@satoshiotomakan satoshiotomakan merged commit 2ed7098 into trustwallet:dev Oct 1, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants