write() syscall length argument (RSI) incorrectly set to caller's PID inside Node child_process execSync — reproducible with and without dynarec

[Gapggyt4]

Environment:
Box64 version: v0.4.3 f79babc (nightly build)
Host: ARM64, Cortex-A520, 8 cores
Distro: Ubuntu inside proot-distro (Termux)
Guest binary: an Electron-based x86_64 Linux app (Node v22.22.0, Electron 39.6.1)
Description:
An Electron/Node application calls child_process.execSync() to run a shell command and capture its output. Internally this triggers a write() syscall to a socket/pipe connected to the child process's stdin. Every time this code path runs, Box64 crashes with SIGSEGV inside box64/syscall.
Key observation:
Across multiple reproductions (different runs, different PIDs), the value in RSI at the time of the crash (write's 3rd argument — buffer length) is consistently equal to the OS PID of the crashing process itself, not the actual length of the buffer being written. This strongly suggests the syscall wrapper is reading the wrong register/context value for the length argument in this particular call path.
Reproduction steps:
Run any Electron app that calls child_process.execSync(cmd) (with or without an input option) early during startup, under Box64.
Crash occurs consistently at the write syscall with EFAULT, RDI staying constant at 0x129 (likely the fd), RSI == PID.
Tested variations (all reproduce identically):
With default dynarec settings
With BOX64_DYNAREC=0 (pure interpreter mode) — rules out a dynarec-specific codegen bug, points to the syscall translation layer itself
With various BOX64_DYNAREC_* env vars (BIGBLOCK, SAFEFLAGS, STRONGMEM, CALLRET) — no effect
Crash signature:
[BOX64] |SIGSEGV @ (syscall) (x64pc=0x302a08b3/"box64/syscall + 0x13", ...)
RDI:0x0000000000000129 RSI: RDX:
Node-side error before the native crash:
Error: write EFAULT
at afterWriteDispatched (node:internal/stream_base_commons:159:15)
at writeGeneric (node:internal/stream_base_commons:150:3)
at Socket._writeGeneric (node:net:966:11)
at Socket._write (node:net:978:8)
at execSync (node:child_process:1000:20)

[ptitSeb]

Is that a libc syscall or an assembly syscall?

[Gapggyt4]

It's a raw syscall, not a libc call. The crash address is inside Box64's own syscall handler:
x64pc=0x302a08b3/"box64/syscall + 0x13"
Even though libc.so.6 is loaded as native(wrapped) per the startup log, the fact that the crash lands in box64/syscall means execution never went through the wrapped libc write() — the guest code issued the SYSCALL (0F 05) opcode directly.
This lines up with how Node/libuv sometimes write to pipes/sockets internally (in stream_base_commons / internal/net) — some of those paths call the raw syscall rather than going through a dynamically-linked libc write(). That would explain why it hits Box64's own syscall translation instead of the native libc wrapper, and why RSI (the length arg) ends up wrong.
I'd confirm this with strace, but ptrace isn't supported in my proot-distro environment proot warning: ptrace request 'PTRACE_???' not supported yet so I can't trace it further from my end.

[ptitSeb]

It's a raw syscall, not a libc call. The crash address is inside Box64's own syscall handler: x64pc=0x302a08b3/"box64/syscall + 0x13"

Well, that's an offset on your local build. Not really helpfull as-is. If you build box64 with debug symbol 'for example as RelWithDebInfo cmake build type), you can then use addr2line -e box64 -a 0x302a08b3 to get the precise line & source file of the issue.

Even though libc.so.6 is loaded as native(wrapped) per the startup log, the fact that the crash lands in box64/syscall means execution never went through the wrapped libc write() — the guest code issued the SYSCALL (0F 05) opcode directly. This lines up with how Node/libuv sometimes write to pipes/sockets internally (in stream_base_commons / internal/net) — some of those paths call the raw syscall rather than going through a dynamically-linked libc write(). That would explain why it hits Box64's own syscall translation instead of the native libc wrapper, and why RSI (the length arg) ends up wrong. I'd confirm this with strace, but ptrace isn't supported in my proot-distro environment proot warning: ptrace request 'PTRACE_???' not supported yet so I can't trace it further from my end.

I would suggest you use BOX64_LOG=1 BOX64_ROLLING_LOG=128 to have the last functions/system calls before the segfault, it might help (because the Write syscall doesn't take any PID in it's argument, so the error might be from some previous system or function call)