Crash at `TEST Ed,Gd` about box64

[ptitSeb]

No, I haven't started looking at this yet, sorry.

[ptitSeb]

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.

[Howard0o0]

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

[Howard0o0]

FYI, here is the way to run the java program.

1. Download and decompress the jdk and javafx.

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.

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

3. Create a script named 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:

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.

[Howard0o0]

Continue tracking this issue. Let me know if more information is needed.

Thanks for the effort!

[Howard0o0]

don't mean to rush, just want to know are there any updates？

[Howard0o0]

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.

box64/src/wrapped/wrappedlibc.c

Lines 2663 to 2669 in b64e6bd

	EXPORT void* my_mmap64(x64emu_t* emu, void *addr, unsigned long length, int prot, int flags, int fd, ssize_t offset)
	{
	(void)emu;
	if(prot&PROT_WRITE)
	prot|=PROT_READ; // PROT_READ is implicit with PROT_WRITE on i386
	if(emu && (box64_log>=LOG_DEBUG || box64_dynarec_log>=LOG_DEBUG)) {printf_log(LOG_NONE, "mmap64(%p, 0x%lx, 0x%x, 0x%x, %d, %ld) => ", addr, length, prot, flags, fd, offset);}
	int new_flags = flags;

box64/src/wrapped/wrappedlibc.c

Lines 2817 to 2821 in b64e6bd

	EXPORT int my_mprotect(x64emu_t* emu, void *addr, unsigned long len, int prot)
	{
	(void)emu;
	if(emu && (box64_log>=LOG_DEBUG || box64_dynarec_log>=LOG_DEBUG)) {printf_log(LOG_NONE, "mprotect(%p, %lu, 0x%x)\n", addr, len, prot);}
	if(prot&PROT_WRITE)

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?

[ptitSeb]

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.

[Howard0o0]

Thanks for the response! I will keep waiting for support from the community.

[Howard0o0]

Is the troubleshooting underway? I noticed that the latest commit in master branch seems to be related to this issue. :D

[ptitSeb]

it wasn't for this issue, but there are a few similar ones. I'll start analysing this issue soon-ish now.

[Howard0o0]

okay