SIGSEGV inside my32___vsnprintf / RELR relocations unsupported

[shakeheartbreak]

Two Box32 issues found while running a 32-bit x86 GL app under box64 v0.4.3 + Box32 on aarch64 (Debian, glibc 2.41).

1. SIGSEGV inside my32___vsnprintf

[BOX32] SIGSEGV @0x... (__vsnprintf) (x64pc=.../"box64/__vsnprintf + 0x13") for accessing 0x100 (code=1/prot=0)

Native BT:
box64(my32___vsnprintf+0x60) /lib/aarch64-linux-gnu/libc.so.6(__vsnprintf+0x78) <- faults

The emulated backtrace below this is garbage (??? [0x3080eca040039f6d]), which looks like a corrupted va_list rather than a wild pointer in the guest. Reproducible on every run. The faulting address shifts (0x100, 0x210) with different guest inputs, always a small offset from null.

2. RELR relocations unsupported

BOX64_EMULATED_LIBS=libc.so.6 aborts before main:

[BOX32] Error: RELR type of Relocation unsupported (only REL)
[BOX32] Error: relocating symbols in elf libc.so.6

Debian's libc6:i386 uses RELR packed relocations, so emulating libc isn't possible on current Debian. This blocks the obvious workaround for (1).

Happy to run any diagnostic build or env var combination you'd like.

[ptitSeb]

I have to check that __vsnprintf issue.

For the libc issue: it's not supported to emulated libc. It should not even be possible, I need to check why it aggrees to use emulated libc.

[shakeheartbreak]

Thanks and I have two extra data points on the __vsnprintf fault:

Reproduces on 7fb6dc4 (master, built today), as well as on v0.4.3 built 18 Jun, so it's not a recent regression.

Across runs the faulting address is always a small offset from null - 0x100, 0x210, 0x380 - and x64pc is always __vsnprintf + 0x13. The
value shifts with the guest's input. The emulated backtrace below the frame is not a plausible 32-bit address (??? [0x3080eca040039f6d]).

Reads to me like the 32->64 va_list conversion is producing a null base rather than the guest passing a wild pointer.. but you'll know better than me 🙏🏼

[ptitSeb]

Could you try to run with BOX64_LOG=2 so we have more details on what is going on?

[shakeheartbreak]

Could you try to run with BOX64_LOG=2 so we have more details on what is going on?

(I've consolidated my previous replies - I know you have a lot on your plate)

I ran with BOX64_LOG=2 as you suggested. It narrowed to what looks like a dynarec/interpreter divergence rather than a vsnprintf problem.

The faulting site resolves (the loader .so is unstripped) to or2snprintf, src/lindbergh/patch.c:186:

39f68: call 1d610 <vsnprintf@plt>
39f6d: add  $0x10,%esp   <-- faults here

So it isn't inside vsnprintf - it's the cdecl stack cleanup on return. or2snprintf va_starts and forwards the va_list, so this path crosses the 32->64 bridge.

The two modes then disagree on the instruction stream. The guest SIGSEGV handler skips:

dynarec:    C3, A2, 0
DYNAREC=0:  C3, A2, EA, 0   + [BOX32] Warning, unexpected new_cs=0xcc00 at 0x3001ae9a

0xEA is the far jump - the interpreter sees it, the dynarec drops it. Once each, both modes, deterministic over ~10 runs.

Env: v0.4.3 (7fb6dc4), Box32, proot Debian on aarch64 (SD 8 Gen 2). Both the loader .so and the guest binary have debug_info, and I can attach the DYNAREC=0 vs dynarec traces around 0x3001ae9a if that's useful.

[shakeheartbreak]

A BOX64_SHOWSEGV dump pins the faulting site to box64's own __vsnprintf:

SIGSEGV @ box64/__vsnprintf + 0x13  (x64pc=0x3001ae93), accessing 0x3430e8a6b6310 (code=1)

That access value is a 32-bit pointer widened into 64-bit space - consistent with or2snprintf (patch.c:186) forwarding a va_list across the 32->64 bridge, which __vsnprintf then walks with a bad pointer. Same site as the earlier 0x3001ae9a divergence.

It cascades rather than crashing once: the guest handler siglongjmps back after each fault but resumes one byte on, so the SIGSEGV walks forward (+0x13, +0x18, +0x1a, +0x1b...) and eventually into putwc (libc.so.6) on a near-null access (0x100). That advancing loop is the CPU-pegging storm.

v0.4.3 (7fb6dc4), Box32, aarch64 and I can share the full block if useful.

[ptitSeb]

I'm not sure what you are debugging here.
First: there is no way the segfault is in add ù0x10, %esp : this is a simple addition of a constant to a register, no memory writting involved here. It's just that box64 is executing some native code and and the x86 RIP register already point to the return address.

If the issue is the alignement function, the 1st thing to do is to print the fmt string! so just add

printf_log(LOG_INFO, "vsnprintf fmt=\"%s\"\n", fmt);

line 1110 in wrappedlibc.c for wrapper32 folder, in my32_vsnprintf to see what fmt is made of, then wi'll see what to do next.

[shakeheartbreak]

Correction on my part: "Skipping SEGFAULT %X" was the handler re-entering vsnprintf after the fault, not the origin.

First SIGSEGV in the log, fmt = "[% 8d] %s":

[BOX32] SIGSEGV @ __vsnprintf +0x13 (x64pc=0x3001ae93) accessing 0x2d0 (code=1)

0x2d0 is near-null - __vsnprintf walking a bad char* for the %s, not a bad fmt.

Every other fmt in the run formats fine, incl %s/%x/%04x/%X/%d
("## OpenGL Error %s(%04x)(%s:%d)", "kswap_collect %d", "EEPROM_READ ADD:%X SIZE:%d").
Only "[% 8d] %s" faults. The single difference is the space flag "% 8d" - no working fmt has one.

v0.4.3 (7fb6dc4), Box32, aarch64. As usual, I've got the full SHOWSEGV block on request. Over to you for your thoughts!

[ptitSeb]

Yeah, the % 8d is not handled. %08d is, but not with a space. I need to fix that.

[ptitSeb]

Ok, I pushed something. Hopefully it will fix the issue.

[shakeheartbreak]

Look what you made possible:

😎

[ptitSeb]

Oh, Arcade version of Outrun 2?! That's nice :D ! Thanks for the feedback and everything!