Possible memory leakage and unhandled exception

[wuwbobo2021]

Possible memory leakage

Test program:

[package]
name = "droid-wrap-min-test"
version = "0.1.0"
edition = "2021"
publish = false

[dependencies]
android-activity = { version = "0.6", features = ["native-activity"] }
droid-wrap-derive = { path = "../derive" }
droid-wrap-utils = { path = "../utils" }

[lib]
name = "droid_wrap_min_test"
crate-type = ["cdylib"]
path = "main.rs"

[package.metadata.android]
package = "com.example.droid_wrap_min_test"
build_targets = [ "aarch64-linux-android" ]

[package.metadata.android.sdk]
min_sdk_version = 16
target_sdk_version = 30

#[no_mangle]
fn android_main(_: android_activity::AndroidApp) {
    loop {
        droid_wrap_utils::vm_attach!(mut env);
        let _ = droid_wrap_utils::wrapper_long_value(3, &mut env);
    }
}

Similar operations may work on PC systems (local references can be freed when env is droped and the thread is detached from JVM). However, it can be different on Android. Please run it on your device and check the RAM usage increment.

In fact it crashes under Android 7.0 (and below):

11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115] local reference table dump:
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]   Last 10 entries (of 511):
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       510: 0x12d52140 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       509: 0x12d52130 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       508: 0x12d52120 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       507: 0x12d52110 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       506: 0x12d52100 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       505: 0x12d520f0 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       504: 0x12d520e0 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       503: 0x12d520d0 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       502: 0x12d520c0 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       501: 0x12d520b0 java.lang.Long
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]   Summary:
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115]       511 of java.lang.Long (511 unique instances)
11-16 05:27:09.408 18430 18444 F art     : art/runtime/indirect_reference_table.cc:115] 
11-16 05:27:09.408 18430 18443 I RustStdoutStderr: referenceTable GDEF length=814 1
11-16 05:27:09.408 18430 18443 I RustStdoutStderr: referenceTable GSUB length=11364 1
11-16 05:27:09.408 18430 18443 I RustStdoutStderr: referenceTable GPOS length=47302 1
11-16 05:27:09.433   856  1849 D audio_hw_primary: start_output_stream: exit
11-16 05:27:09.468 18430 18444 F art     : art/runtime/barrier.cc:90] Check failed: count_ == 0 (count_=-1, 0=0) Attempted to destroy barrier with non zero count
11-16 05:27:09.468 18430 18444 F art     : art/runtime/runtime.cc:366] Runtime aborting --- recursively, so no thread-specific detail!
11-16 05:27:09.468 18430 18444 F art     : art/runtime/runtime.cc:366] 
--------- beginning of crash
11-16 05:27:09.468 18430 18444 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 18444 (android_main)

a possible way to fix it (however, if it were to be done, there would be lots of other places to be changed):

pub fn wrapper_long_value(value: i64, env: &mut JNIEnv) -> GlobalRef {
    let obj = env
        .new_object("java/lang/Long", "(J)V", &[value.into()])
        .map(|o| env.auto_local(o)) // Added
        .unwrap();
    env.new_global_ref(&obj).unwrap()
}

Possible unhandled exception

I have realized the ambition behind this project, but it's undocumented that how to use derive macros on Java functions with non-primitive object parameters. And I don't how Java exceptions are handled in this library.

The jni-rs problem described below happens on both PC and Android. Here's a test program on PC:

[package]
name = "jni-env"
version = "0.1.0"
edition = "2021"

[dependencies]
jni = { version = "0.21.1", features = ["invocation"] }

fn main() {
    let args = jni::InitArgsBuilder::new()
        .version(jni::JNIVersion::V8)
        .build()
        .unwrap();
    let vm = JavaVM::new(args).unwrap();
    let mut env = vm.attach_current_thread().unwrap();
    println!("{:?}", java_parse_int(&mut env, "3"));
    println!("{:?}", java_parse_int(&mut env, "s"));
    println!("{:?}", java_parse_int(&mut env, "5"));
}

fn java_parse_int(env: &mut JNIEnv, s: &str) -> Result<i32, Error> {
    let java_string = env.new_string(s).unwrap();
    env.call_static_method(
        "java/lang/Integer",
        "parseInt",
        "(Ljava/lang/String;)I",
        &[(&java_string).into()]
    )
    .map_err(|e| { env.exception_clear().unwrap(); e })
    .and_then(|o| o.i())
}

Output:

Ok(3)
Err(JavaException)
Ok(5)

After commenting .map_err(|e| { env.exception_clear().unwrap(); e }), it would crash on the third java_parse_int():

Ok(3)
Err(JavaException)
thread 'main' panicked at src/main.rs:21:41:
called `Result::unwrap()` on an `Err` value: JavaException
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Exception in thread "Thread-0" java.lang.NumberFormatException: For input string: "s"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:580)
        at java.lang.Integer.parseInt(Integer.java:615)

[mzdk100]

根据您的运行结果看：

Ok(3)
Err(JavaException)
thread 'main' panicked at src/main.rs:21:41:
...

这说明exception_clear()函数运行不正常，但我认为我们其实无需理会，可以直接这样写env.exception_clear().unwrap_or(())。

[wuwbobo2021]

您误会了。我认为，panic 正是在 exception_clear() 未被执行的情况下继续进行其他 JNI 操作的结果，而非 exception_clear() 执行不正常。实际上我还没有遇到异常清除失败的情况。

[wuwbobo2021]

I just realized that JNIEnv::attach_current_thread_permanently() is called within the android_main() execution thread created in the application entry point in android_activity crate. (it seems like you prefer another way of introducing entry point). It prevents automatic detaching from the JVM, thus local references will not be freed automatically.

Besides, I can’t find any exception_clear() in your code. Is there any other way to prevent it from panicking?

[mzdk100]

I see that the wrapper_long_value function you fixed is very great. Also using exception_clear. Can you push a PR?

[wuwbobo2021]

I didn’t expect myself to be a named contributor of this project. As I mentioned above, there may be some other places that needs to be fixed or even reconstructed, and I may not realize all of them, because I’m not an author of the complicated code.

For droid-wrap-derive, I cannot use it for now, because I don’t know how to generate bindings for Java functions with non-primitive parameters (other than generated proxies), calling it and catching possible exceptions.

I may try to extract and rewrite the invocation handler helper from your code and create a new minimum crate. Of course I’ll mention your project in the documentation.

Anyway, thank you for inspiration.

[mzdk100]

If that's the case, I will add the solution you provided to the droid-wrap, but it will take some time.
There is still much room for improvement in the entire droid-wrap library, such as the automatic binding of array types that I am currently working on.
The emergence of this project is also an attempt, and it is inevitable that there will be some shortcomings.

[wuwbobo2021]

I just realized that java_method derive macro can have some parameters overload (?) and type_bound=(<RustType>, <JavaClass>). However, not being an experienced prigrammer, I don’t dare to use these undocumented features.

[mzdk100]

In the Java world, method overloading is a common practice, which means allowing multiple methods with the same name but different numbers or types of parameters. However, this is not allowed in the Rust world. Therefore, the solution is to define different named methods in Rust and inform the java_method macro on how to handle this situation.
For examples of usage, you can check the src/android/view.rs file (search for overload).
Regarding the type_bounds parameter, it can be ignored for now as it is used by the framework layer, and I am not confident in explaining it clearly.

[wuwbobo2021]

I’ve published my minimal crate: https://crates.io/crates/jni-min-helper. Would you please check it?

[mzdk100]

Your crate handles JNI errors very pretty. If you can continue to maintain it in the future, I will add it as an upstream to the droid-wrap.

[wuwbobo2021]

A fatal exception may occur when unregistering a receiver that isn't registered (including auto dropping cases). It's caused by https://docs.rs/jni-min-helper/0.1.1/src/jni_min_helper/proxy.rs.html#427-437 dropping the env. The newest version fixed it. All previous versions were yanked.

[Alphapage]

I'm trying to use fn android_main(_: android_activity::AndroidApp) { as @wuwbobo2021 without success.
But I don't understand if it is better to use previous entry or @mzdk100 entry point refering to (#2 (comment)).
Thank you in advance to give me your point of view and a way to use android_activity entrypoint if this is the best solution.

[mzdk100]

Reference droid-wrap example

git clone https://github.com/mzdk100/droid-wrap.git
cd droid-wrap
cargo install cargo-apk2
cargo apk2 run -p droid-wrap-example --example activity-example

Building should be easy to succeed!