[BOX32] SourcePawn JIT crashes with free(): invalid pointer on L4D2 dedicated server

[7DSByZz]

[[[[[[[[[

Box64 version: v0.4.3 148a1a2
OS: Ubuntu 24.04 ARM64 (Oracle Cloud, Neoverse-N1)
Game: Left 4 Dead 2 dedicated server (32-bit srcds_linux)

When SourceMod loads sourcepawn.jit.x86.so under BOX32, the server crashes with:
free(): invalid pointer
SIGABRT at box64/free + 0x13

The JIT allocates memory with mmap but Box32 tries to free it with the system free().

Stack trace shows:
__libc_free -> box64/free -> sourcepawn.jit.x86.so

Workaround attempted: BOX64_DYNAREC=0, BOX64_MALLOC_HACK=2, LD_PRELOAD jemalloc — none worked.

Is there a way to make Box32 handle mmap-allocated memory correctly when freed via free()?

Additional context:

• The server was installed using DepotDownloader (not SteamCMD), so there is
  no ~/.steam/steambeta/ - Box64 + Box32 is used directly with srcds_run.
• MetaMod (1.12 i486) and SourceMod (1.11 i486) load correctly up to the
  point of initializing sourcepawn.jit.x86.so.
• The crash happens right after "Using emulated .../sourcepawn.jit.x86.so"
  when attempting to load the first plugin (.smx).
• Also tested with SourceMod 1.10 and 1.11, same result.
• Without SourceMod, the server runs perfectly stable (pure Box32, no JIT).

Additional question: is there a SourceMod build compiled natively for
ARM64/aarch64 that would avoid going through 32-bit emulation entirely?
That would be the ideal solution if Box32 can't be fixed short-term.

Launch command used:
box64 ./srcds_run -game left4dead2 -console -usercon +map c1m1_hotel +maxplayers 8 -port 27020

Relevant VDF files:
metamod.vdf -> addons/metamod/bin/server_i486
sourcemod.vdf -> addons/sourcemod/bin/sourcemod_mm_i486]]]]]]]]]]]

Versión de Box64: v0.4.3 148a1a2
Sistema: Ubuntu 24.04 ARM64 (Oracle Cloud, Neoverse-N1)
Juego: Servidor dedicado de Left 4 Dead 2 (srcds_linux de 32 bits)

Cuando SourceMod carga sourcepawn.jit.x86.so bajo BOX32, el servidor crashea con:
free(): invalid pointer
SIGABRT en box64/free + 0x13

El JIT aloca memoria con mmap pero Box32 intenta liberarla con el free() del sistema.

El stack trace muestra:
__libc_free -> box64/free -> sourcepawn.jit.x86.so

Intenté: BOX64_DYNAREC=0, BOX64_MALLOC_HACK=2, LD_PRELOAD con jemalloc — ninguno funcionó.

¿Hay alguna forma de hacer que Box32 maneje correctamente la memoria alocada con mmap cuando se libera con free()?

Contexto adicional:

• El servidor fue instalado con DepotDownloader (no SteamCMD), por lo que no
  existe ~/.steam/steambeta/ - solo se usa Box64 + Box32 directamente con srcds_run.
• MetaMod (1.12 i486) y SourceMod (1.11 i486) cargan correctamente hasta el
  punto de inicializar sourcepawn.jit.x86.so.
• El crash ocurre justo después de "Using emulated .../sourcepawn.jit.x86.so"
  al intentar cargar el primer plugin (.smx).
• Probé también con SourceMod 1.10 y 1.11, mismo resultado.
• Sin SourceMod, el servidor corre perfectamente estable (Box32 puro, sin JIT).

Pregunta adicional: ¿existe alguna build de SourceMod compilada nativamente
para ARM64/aarch64 que evite pasar por la emulación 32-bit por completo?
Eso sería la solución ideal si Box32 no puede resolverse a corto plazo.

Comando de arranque usado:
box64 ./srcds_run -game left4dead2 -console -usercon +map c1m1_hotel +maxplayers 8 -port 27020

Archivos VDF relevantes:
metamod.vdf -> addons/metamod/bin/server_i486
sourcemod.vdf -> addons/sourcemod/bin/sourcemod_mm_i486

[ptitSeb]

The JIT allocates memory with mmap but Box32 tries to free it with the system free().

How do you know the emory is allocated with mmap?

[7DSByZz]

Good question — and honestly, my original statement was an assumption, not something I had verified. I went back and checked.

I traced the actual crashing PID (37990, confirmed via [BOX32] 37990|SIGABRT) and grepped every mmap call it made, then checked whether the crash address (0x3e900009466) falls inside any of them:

import re
target = 0x3e900009466
with open("strace_output.txt") as f:
    for line in f:
        if not line.startswith("37990 mmap"):
            continue
        m = re.search(r"mmap\((?:0x([0-9a-f]+)|NULL), (\d+),.*= 0x([0-9a-f]+)", line)
        if not m:
            continue
        length = int(m.group(2))
        base = int(m.group(3), 16)
        if base <= target < base + length:
            print("MATCH:", line.strip())

MATCH: 37990 mmap(NULL, 1099511627776, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a0d9a00000

So the address does NOT correspond to its own individual mmap call. It falls inside one of the large startup reservations (1TB, PROT_NONE) — part of what looks like the probing sequence for the "Memory higher than 32bits reserved" region I saw earlier in the log.

So to correct myself: I don't have evidence the JIT calls mmap directly for this allocation. What I can say is that the crashing pointer lives inside that large high-memory reservation, which is presumably sub-allocated internally (by Box64/Box32's own allocator) rather than via individual mmap/malloc syscalls — which would explain why this pointer isn't recognized as valid by the real free().

Is that consistent with how that high-memory region is managed internally? Happy to grab any additional traces if that'd help narrow it down further.

[ptitSeb]

This reverved memory can be used internaly for 64bits memory allocation indeed. But then, it's a 64bits pointer, so the miss-free is from box64 itself. It would be interesting to get a full gdb backtrace of the faulty free...

[7DSByZz]

Hi! I've been slow to reply because I was at work, sorry. I was having trouble figuring out what you said, but here it is. I hope this helps (I sent the whole thing just in case, sorry if it's too much text :p). I used these commands to get there: gdb --args box64 ./srcds_linux -game left4dead2 -console -usercon +map c1m1_hotel +maxplayers 8 -port 27020 -nomaster handle SIGSEGV nostop noprint pass handle SIGILL nostop noprint pass handle SIGBUS nostop noprint pass run thread apply all bt.

Logs.txt