Crash at TEST Ed,Gd
#1445
Comments
|
Can you put the jvm/jre you used and the .java binary also, for local debugging? I have run some java games succesfully already, so it should work. |
|
The jdk and javafx is too large to upload, so I put the link. jdk: https://aka.ms/download-jdk/microsoft-jdk-11.0.22-linux-x64.tar.gz .java files: |
|
FYI, here is the way to run the java program.
cd /tmp
wget https://aka.ms/download-jdk/microsoft-jdk-11.0.22-linux-x64.tar.gz
wget https://download2.gluonhq.com/openjfx/11.0.2/openjfx-11.0.2_linux-x64_bin-sdk.zip
tar -xvf microsoft-jdk-11.0.22-linux-x64.tar.gz
unzip openjfx-11.0.2_linux-x64_bin-sdk.zip
mv javafx-sdk-11.0.2 jdk-11.0.22+7/
cd /tmp
wget https://github.com/ptitSeb/box64/files/14971196/java-program.zip
unzip java-program.zip
# Now we will see HelloJNI.class and HelloJNI.java
# run.sh
JAVA_HOME=/tmp/jdk-11.0.22+7
PATH=$JAVA_HOME/bin:$PATH:.
CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar:.
export JAVA_HOME
export PATH
export CLASSPATH
export PATH_TO_JAVAFX="${JAVA_HOME}/javafx-sdk-11.0.2/lib"
BOX64_LOG=1 BOX64_DLSYM_ERROR=1 BOX64_TRACE_XMM=1 BOX64_JITGDB=1 BOX64_TRACE=1 box64 java -Dprism.order=sw --module-path ${PATH_TO_JAVAFX} --add-modules javafx.controls -Djava.library.path=. HelloJNIIt's just a simple Java demo that creates a window using the JavaFX library. If we use an ARM64 native JVM to run this Java program, the expected result is a window popping up on the screen like this: This issue is easy to reproduce, although there is a small chance that it might not occur, with approximately a 5% probability of running normally. |
|
Continue tracking this issue. Let me know if more information is needed. Thanks for the effort! |
|
don't mean to rush, just want to know are there any updates？ |
|
No, I haven't started looking at this yet, sorry. |
|
I suspect that Java allocates a memory area using mmap64, and box64 returns the area at I reviewed the logs for box64/src/wrapped/wrappedlibc.c Lines 2663 to 2669 in b64e6bd box64/src/wrapped/wrappedlibc.c Lines 2817 to 2821 in b64e6bd Here is the related log: Thus, the assumption appears to be correct: Java allocates an area and marks it as reserved. However, why does |
|
This is probably a stack. And the 4096 byte (a page) that are protected is the "stack guard" to detect stack overflow. The error is probably comming from some place else, like a stack search for something. I still haven't started debugging this one. |
|
Thanks for the response! I will keep waiting for support from the community. |
|
Is the troubleshooting underway? I noticed that the latest commit in master branch seems to be related to this issue. :D |
|
it wasn't for this issue, but there are a few similar ones. I'll start analysing this issue soon-ish now. |
|
okay |
Running a Java program with an x64 JVM, Box64 would crash at
TEST Ed, Gd.Box64 LOG
GDB
It seems that
opedpoints to an invalid address,0x60000008, because0x60000008appears to be in a reserved memory space.I searched the memory address
0x60000000in the box64 code and found#define HIGH (void*)0x60000000. However, I still have no idea whyEDpoints to a reserved memory address.Environment
d53ff127on branch main.Java Code:
Comamnd compiling the java code:
javac --module-path ${PATH_TO_JAVAFX} --add-modules javafx.controls HelloJNI.javaThe text was updated successfully, but these errors were encountered: