Open johanvos opened 5 years ago
@loicottet can we try this with the LLVM backend to see if the problem goes away?
FYI, here is the native-image command I execute on an AArch64 server to generate hello.helloworld.o
#!/bin/bash
export CP=/home/ubuntu/fork/client-samples/Gradle/HelloWorld/build/classes/java/main
export GRAAL=/home/ubuntu/graal/vm/mxbuild/linux-aarch64/GRAALVM_UNKNOWN/graalvm-unknown-19.3.0-dev
$GRAAL/bin/native-image \
--no-fallback -H:TempDirectory=/tmp/tmphw \
-H:+SpawnIsolates \
-H:+ExitAfterRelocatableImageWrite \
-H:+UseOnlyWritableBootImageHeap \
-H:+ReportExceptionStackTraces \
-H:+AllowIncompleteClasspath \
-cp $CP \
hello.HelloWorld
There is a possibility that this issue is related to my #1704 (also due to SIGSEGV).
We just tried the same code with the LLVM backend (aarch64isolates branch from @loicottet ) and so far, no crashes.
We have a HelloWorld java app, compiled with native-image, linked into a shared library, loaded into an Android activity. That works fine, HelloWorld is printed. More complex Java apps work fine as well.
However, we run into issues with JNI calls that seem to indicate there is some memory corruption when invoking/returning from Java to native. On https://github.com/johanvos/grandroid I have a standalone reproducable setup. The Java source code that is native-imaged into a .o file (on an AArch64 machine) is at https://github.com/johanvos/client-samples/tree/egl/Gradle/HelloWorld
There is a test that is executed in this Java code, that calls 4 native functions. Running this with the hellohwgl.sh script in the grandroid repo on an android phone will cause a crash, due to a sigsegv in libGLESv2_adreno.so . The native implentations of the 4 functions are in the grandroid project, in glass_android.c
That file has a switch:
#define ALL_NATIVE 1
If that is set, the call to the second native function will also invoke the third and the fourth, without going back to Java. In this case, there is no crash.There is no Java functionality between the different native calls. Hence, if the 4 native functions are combined into 2 bigger native functions, it all works fine. If the native functions are called one by one, there is a crash.
Note that the x0 register points to an address in the JNIEnv structure, which is not what you would expect in the functionality being executed (EGL calls, completely away from JNIEnv).
In the native calls, JNIEnv* is passed as the first parameter, and it is at 0x79d0e54000
Here is the crash info: