Calling java method with incorrect params crashes with a JNI exception

[petekanev]

Problem:
After trying to implement a library (http://writingminds.github.io/ffmpeg-android-java), and trying to call a method with the incorrect parameters

Calling the native API

ffmpeg.execute('-version', new MyCustomExecuteBinaryResponseHandler());

the application crashes abruptly with the following JNI exception:

JNI DETECTED ERROR IN APPLICATION: bad arguments passed to void com.github.hiteshsondhi88.libffmpeg.FFmpeg.execute(java.lang.String[], com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteResponseHandler) (see above for details)

The exception indicates that the method was called with the wrong parameter types. The problem here is that the runtime should have thrown an exception which can be handled in debug configuration, showing an error activity instead.

Error: java.lang.Exception: Failed resolving method execute on class com.github.hiteshsondhi88.libffmpeg.FFmpeg

Debugging the callstack reveals that the CallJavaMethod https://github.com/NativeScript/android-runtime/blob/8d849ea6f15ab492ab83767eb15c429d8f9b7e04/runtime/src/main/jni/CallbackHandlers.cpp#L210 reads the method as resolved, as marked by the metadata generator, and doesn't compare the incoming parameters to those expected by the Java method in order to find the best-matching proper method, if any.

Repro steps:
Given the following simple Java class:

package com.tns;

public class TestJavaClass {
    public void callMeWithAString(java.lang.String[] cmd, Runnable arbitraryInterface) {
        String res = "I lied, call me with an array!";
        android.util.Log.d("Log", "callMeWithAString called.");
    }
}

Call in Js like so:

    let myClazz = new com.tns.TestJavaClass();

    myClazz.callMeWithAString("Here!", new java.lang.Runnable({ run: () => { }}));

Solution:
Investigate further why the method is considered resolved and doesn't check the arguments against the expected method signature.

1. Evaluate whether this "optimization" should remain, or go in favor of always resolving method overloads against the parameters passed. - Unlikely
2. Add signal handlers and throw an exception explaining how the user can debug the problem.

[petekanev]

Registering signal handlers using NDK's signal() doesn't work the same between versions 17 and 26, tested on emulators. Also, if a signal handler is called, the signal may not necessarily be raised by a method that is not called correctly.

[vtrifonov]

What we did was to implement signal handling for API versions > 25 as they don't crash after handling that signal. For now we've decided to go this way as adding additional logic for determining which overload exactly to call might result in a performance hit.