Aarch64 android calling Java function in host function aborts #1379
Comments
MarkMcCaskey
added
the
🕵️ needs investigation
|
Have you enabled logging with Here are the related codes in my app:
|
|
Couldnt get your panic to work quite the same due to various compilation errors. However with the following changes that I made to I get the following log: In the log we can see that the two function calls before entering WASM work and print and src/lib.rs:51 is |
|
From the above log we can see that the succeeding and failing calls have identical apart from failing call getting some exception in the middle of the call and never printing. Here is a diff of a successful call (success.log) and the failing call (fail.log) showing how they look the same in the log apart from an exception that seems to occur during the call from host function: --- success.log 2020-04-15 13:52:39.813318990 +0300
+++ fail.log 2020-04-15 13:52:49.757414699 +0300
@@ -15,12 +15,12 @@
calling checked jni method: CallVoidMethodA
looking up jni method CallVoidMethodA
found jni method
-I/System.out: Test was called from WASM!
checking for exception
calling unchecked jni method: ExceptionCheck
looking up jni method ExceptionCheck
found jni method
- no exception found
+ exception found, returning error
calling unchecked jni method: DeleteLocalRef
looking up jni method DeleteLocalRef
found jni method
+E/wasmer_android: ERR: panicked at 'called `Result::unwrap()` on an `Err` value: Error(JavaException, State { next_error: None, backtrace: InternalBacktrace })', src/lib.rs:85:5 |
|
You can throw the exception from Rust code by Now, the log message reports an error exactly same with iijlab/wasmonandroid#1: |
|
As written in iijlab/wasmonandroid#1, I thought this was because my code consumes stack too much until getting this issue. @MarkMcCaskey |
|
Sorry, this can be a known issue of Android, according to https://stackoverflow.com/questions/27223005/unable-to-make-jni-call-from-c-to-java-in-android-lollipop-using-jni and https://issuetracker.google.com/issues/37035211. |
wasmerio/wasmer#1379 is caused when calling a Java method from a wasm file via imports. That prevents the wasm file from calling even android_logger. So I switched to use simplelog to write log on a file
|
Progress report of debugging: To show log while running wasmer, I switched the logger to write on the application data: igrep/wasmer_android_jnicall_repro@6387f88 Now, we can see the log written by libwasmer_android.so with this command after running the app: I'm going to add debug codes to wasmer from now on. |
|
Progress report: I tried two ways to fix after adding loggings:
|
|
A bit out of my expertise, but based on the comments in the threads you linked earlier and based on
I would say that the native function call should be moved to some other context which is outside of this signal handling if possible - if that indeed is the reason for the issue. There must be something that wasmer does to create this situation where it is not possible to call java as the java calls normally work outside of wasmer. Relocating the native call to outside of that or removing the error creating code or correcting it if done wrong would be the solution in my mind. ps. really nice stuff here. definitely taking some of this logging and error handling to use. |
|
Thanks for figuring this out! It looks like our signal handling code is not built to be used outside of a wasm context. I'm not familiar with the details here at all, but it seems highly plausible that the signal handling of Wasmer and the Android runtime could be interacting poorly. This seems like a problem that would show up in quite a few places actually, I'm not sure what the standard solutions are for conflicting signal handling code... I'll look into this later if I have the bandwidth and post any ideas I have! |
…ignal handler But actually the result didn't change
|
After browsing the source code of Android and wasmer, I suspect this is just because wasmer alters Now, I'm interested in why the singlepass backend for AArch64 is implemented in such a way, and how to fix it? |
|
We are planning a new version of the Singlepass compiler to support aarch 32 and 64bits. See #2463. Also, I would like to point this |
|
This should be already fixed on master, it needs a test case to prove that |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Feel free to reopen the issue if it has been closed by mistake. |
Describe the bug
I am trying to run wasmer embedded in an android app and call android app functions from WASM.
This succeeds on x86_64 emulator, but not on an ARM phone.
When an android class instance's method is being called from a host function exposed to WASM the program aborts.
I have attached a reproduction case where there is a WASM module, an android wasmer runtime and an android project that uses the wasm module and wasmer runtime.
The application loads the wasmer runtime as a shared library. It then loads the wasm module from assets folder as byte array and calls a function of the wasmer runtime through JNI. In this call the runtime gets the module bytes, the instance of the java class and java environment.
The function will load the wasm module so it is ready to execute, shows how a test JNI call works outside of wasmer runtime, places java class and vm references to global variables and runs the wasm module.
The wasm module simply executes the Test host function (named java_test in rust) in it's main function.
The host function gets the java environment and class instance from the global variables and uses them to do a function call into Java again. This call should be the exact same as the JNI function call performed earlier.
The running of the wasm module works on x86_64, but not on a real phone using aarch64 build.
The JNI function call succeeds outside of wasmer code, but not inside the wasmer host function.
Steps to reproduce
(also attached as zip: wasmer_android_jnicall_repro-master.zip)
Expected behavior
The program runs without aborting on both x86_64 and aarch64.
Log of x86_64 succeeding (program finishes cleanly and all prints appear):
Actual behavior
The program works on x86_64, but aborts during a JNI call in a host function on aarch64.
Log of aarch64 failing (last 3 lines show how the call aborted):
Additional context
Pretty new to android, JNI and wasm so it is entirely possible I have a simple logical error in my code. However the code working on x86_64 suggests that might not be the case.
Unsure if this is an issue in my code, JNI code or wasmer code, but it only appears in wasmer host function.
The text was updated successfully, but these errors were encountered: