Potential Race Condition or Garbage Collection Issue during JNI Environment Usage

[ribelo]

Description

The issue arises when a JVM exception is thrown before invoking JNI code, leading to a garbage collection and race condition problem. This results in the env variable not existing in the following line:

let obj = env.new_object_unchecked(cls, constructor, &offsets_vec[..]).unwrap();

Expected Behavior

The expected behavior is for the environment object to be properly accessible. It would be nice if an exception were thrown instead of the JVM being crashed.

Error Message

thread '<unnamed>' panicked at src/lib.rs:442:22:
called `Result::unwrap()` on an `Err` value: JavaException
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
rlwrap: warning: clojure crashed, killed by SIGABRT (core dumped).
rlwrap itself has not crashed, but for transparency,
it will now kill itself with the same signal

How to Reproduce?

The error can most effectively be replicated by employing infinite recursion to generate tokens. I not providing a specific example because we use Clojure, which has too many parentheses to fit into an example.

Steps to reproduce

Like above.

What have you tried to solve it?

• Reviewing the rust/JNI code

Environment Info

Since the issue is related to JNI and JVM interaction, rather than a problem specific to the DJL framework, running ./gradlew debugEnv as suggested might not provide the relevant environmental information needed to debug this issue.

[frankfliu]

In JNI, if a java exception is thrown, it will continue to execute the next line of JNI code until the function returns. Handling java exception in JNI code is quite cumbersome.

trying to understand if the cause of the exception is a common case, or an user error. Do you have a minimal reproduce code?