Files

MechaCat02 ad45873a1b ITERATE-2.V: scheduler priority aging closes 18-day AUDIT-049 wedge

Priority aging in xenia-cpu/scheduler.rs:pick_runnable
(effective_priority = base + age_bonus(now_round - last_run_round),
capped at +31, AGING_ROUNDS_PER_BONUS=1). Strict-priority was parking
priority=0 threads behind CPU-bound priority=15 audio mixer
(sub_824D1328 guest spinwait at PC=0x824d1404 on CPU5). Aging
eventually picks the starved thread, breaking the producer-consumer
cycle that caused 5-tid wedge at PC=0x824ac578 since AUDIT-049 (10 May).

Cascade observed: tid=13 clean exit; events 121K -> 13M (107x); last
host_ns 767ms -> 51,011ms (66x); 8 new threads spawn; VdSwap 1 -> 2.

Complete two-day iterate sequence (2026-05-27 -> 2026-05-28):
- 2.F: VdSwap drain timeout 900ms -> 1ms (xenia-gpu/handle.rs); 876x
       perf win on VdSwap kernel callback
- 2.H: vA0000000 physical heap bucket added (state.rs, exports.rs);
       ctx_ptrs now in 0xA0000000-0xBFFFFFFF range matching canary
- 2.L: Phase-A diff harness categorized [return_value mismatch],
       [status mismatch], [args_resolved.path mismatch] tags
       (tools/diff-events/diff_events.py); closes reading-error #41
       (silent test-harness state leak invalidating trace diffs)
- 2.M: always-on exit-thread-state.json sibling to Phase-A JSONL
       (event_log.rs + xenia-app/main.rs); closes reading-error #42
       (Phase-A blind to blocked-forever waits)
- 2.Q: signal.match kernel instrumentation in NtSetEvent /
       NtReleaseSemaphore / KeSetEvent / KeReleaseSemaphore
       (exports.rs); emits target_handle + waiter_count + waiter_tids
- 2.T: wake.requested kernel instrumentation in wake_eligible_waiters
       (exports.rs); emits target_tid + transition + new_state
- 2.V: scheduler priority aging (xenia-cpu/scheduler.rs) [keystone]

Plus accumulated WIP from earlier May (contention_manifest,
phase_b_snapshot, xam/xaudio enhancements, analysis db, xex loader,
xenia-app main loop, etc.). Audit-runs/ artifacts remain untracked
per project convention.

Tests: 300 xenia-cpu / 227 xenia-kernel / 5 xenia-app / 19 xenia-path
/ 30+ smaller suites -- all PASS, 0 regressions. Determinism preserved
(2x cold runs bit-identical at 13,003,881 events post-2.V).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-29 07:27:26 +02:00

3.7 KiB

Raw Blame History

address, classification, confidence, last_audit, aliases

address

classification

confidence

last_audit

aliases

0x8245FEB8

normal_callee

high

060

vptr installer for dispatch_table 0x820B5830

AUDIT-059 'dead' (FALSIFIED)

sub_8245FEB8 — vptr installer for dispatch_table 0x820B5830

Synopsis

Installs a vtable pointer / dispatch-table entry into a runtime-allocated object. Body contains stw r11, 0(r31) at 0x8245FFC0 writing the vtable address to the object's slot 0. After install, the object's bctrl dispatch reaches the methods in dispatch_table @ 0x820B5830 (slot 0 = sub_8245F1D0, slot 1 = sub_8245EC10). Fires 5× in ours / 2× in canary; lives in the AUDIT-050 worker cluster but is NOT dead in either engine — both engines reach the same call site sub_824601A0+0x68 (PC=0x82460208).

Evidence

Body opcode at 0x8245FFC0: stw r11, 0(r31) — vtable install pattern.
Two static callers per xrefs table (source_func):
- sub_824601A0 at +0x68 (PC 0x82460208) — 1 site
- sub_8245FB68 at +0x198 and +0x1C0 (PCs 0x8245FD00 and 0x8245FD28) — 2 sites
AUDIT-060 Probe C-Win Windows Debug canary: --log_lr_on_pc=0x8245FEB8, 120s → 2 fires, both lr=0x8246020C (= sub_824601A0+0x6C, post-bl PC). r3=BC365C40 (same object), r4=4 then r4=1 (different slot indices), r31=701CF2E0 then r31=705AFAA0 (different threads).
AUDIT-060 Probe O ours: --ctor-probe=0x8245FEB8 -n 500M → 5 fires total: 1 from tid=1 boot path at cycle 5.5M via sub_824601A0+0x68, 3 more from tid=1 during UI inflation, 1 on tid=13 at cycle 23788 via the wedge chain.
The r4 parameter (slot index) and the r31 saved value diverge per call; install target object differs.

Activation

Direct bl from one of:

sub_824601A0+0x68 (most frequent — boot path)
sub_8245FB68+0x198 and +0x1C0 (internal lib path, sub_8245FB68 itself has callers sub_8245F880, sub_8245FAB0)

Caller chain upward: sub_824601A0 ← sub_82460118 ← sub_82452AB8 ← sub_82452DC0. The vptr-install path piggybacks on the work-submitter cluster.

Static graph

Callers: sub_824601A0, sub_8245FB68.
Body: vtable write at +0x108 (0x8245FFC0). Other body content not yet detailed.
The vtable being installed is implicit in caller-supplied r11 (and possibly elsewhere).

Audit log

AUDIT-060 (2026-05-12) — measured 5× ours, 2× canary, identical call site both engines. AUDIT-059's framing falsified. Convergence to AUDIT-050 work-submitter cluster confirmed. [confirmed]
AUDIT-059 (2026-05-11) — claimed as "vptr installer dead in ours" because static graph showed sub_8245EC10 (slot 1 of the installed dispatch table) had 0 static callers reachable from any caller-chain that DB classified as live. [STATUS: falsified by AUDIT-060 — was alive in ours all along; the DB caller-chain reachability call was too narrow.]

Open questions

What is the class being installed? (Read r11 at the stw r11, 0(r31) site — canary trace shows it's a specific dispatch table.)
The 5 ours fires vs 2 canary fires — is this a parity match (canary just had only 2 because of the same AUDIT-056 3.21× upstream gate) or does ours over-fire? Aligning instruction-horizon vs wallclock would clarify.
Slot-1 method sub_8245EC10 is named the canary signaler B. It fires 2× in ours per AUDIT-060 — but not on the wedge handle (per AUDIT-059 ours signal_attempts=0 on 0x12AC). What handle is it signaling in ours?

Cross-references

Installs dispatch_table at: 0x820B5830
Slot 0: sub_8245F1D0 (referenced; not yet dossierd)
Slot 1: sub_8245EC10
Direct callers: sub_824601A0, sub_8245FB68
Audits: 059, 060
Artifacts: audit-runs/audit-059-gamma-wedge/, audit-runs/audit-060-fnptr-array-bootstrap/

3.7 KiB Raw Blame History Unescape Escape