Open Howard0o0 opened 3 months ago
0x60000000
is not a reserved area. It's just an arbitrary value used as a starting point for mmap64.
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 javafx: https://download2.gluonhq.com/openjfx/11.0.2/openjfx-11.0.2_linux-x64_bin-sdk.zip
.java files: java-program.zip
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/
2. Download the java src/binary files.
```bash
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
that is located in the same directory as HelloJNI.class.
# 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=. HelloJNI
It'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:
<img width="299" alt="image" src="https://github.com/ptitSeb/box64/assets/32026856/cb6d474f-b1c4-4d0d-a143-96ab825ebbdb">
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 0x60000000
. Subsequently, Java changes the privileges of this area to ---p
by invoking mprotect
.
I reviewed the logs for my_mmap64
and my_mprotect
to monitor the area at 0x60000000
.
Here is the related log:
mmap64((nil), 0x1000, 0x3, 0x22, -1, 0) => mprotect(0x60000000, 4096, 0x6)
mprotect(0x60000000, 4096, 0x6)
mprotect(0x60000000, 4096, 0x0)
Thus, the assumption appears to be correct: Java allocates an area and marks it as reserved.
However, why does ED
point to this reserved area?
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
oped
points to an invalid address,0x60000008
, because0x60000008
appears to be in a reserved memory space.I searched the memory address
0x60000000
in the box64 code and found#define HIGH (void*)0x60000000
. However, I still have no idea whyED
points to a reserved memory address.Environment
d53ff127
on branch main.Java Code:
Comamnd compiling the java code: