fabi/xenia-rs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a4926c73f40b2fa574f9bb6aca837e543218f506
xenia-rs/audit-runs/audit-069-wait-signal-producer/s3/handle-sequence-diff.md
MechaCat02 ef93a4fa14 handoff: VSync/event-wedge fixes + iterate 2.A–2.BC research notes 
Source changes (dormant parity infra, retained from iterate 2.AI/2.AO):
- xenia-kernel/exports.rs: nt_create_event manual_reset polarity +
  related event wiring
- xenia-gpu/mmio_region.rs: D1MODE_VBLANK_VLINE_STATUS hardcode parity

Also lands the audit-runs/ analysis notes (.md/.txt/.json digests) for the
iterate 2.x VSync/0x10e8/0x1004 wedge investigation. Raw trace dumps
(.jsonl/.gz/.csv/.stdout) and agent worktrees (.claude/) are gitignored as
regenerable local artifacts — see memory + HANDOFF for the running findings.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-05 07:19:08 +02:00

144 lines
7.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AUDIT-069 Session 3 — handle-sequence diff (ours tid=5 vs canary tid=10)
Two engines run γ-signaler family on identical thread (entry=0x82450A28, ctx=0x828F3B68).
ours labels this thread tid=5; canary labels it tid=10 (cross-engine tid mismatch, AUDIT-068 reading-error #28).
## Fire-count summary
| caller LR | symbol | wrapper PC | ours fires | canary fires | ratio |
|---|---|---|---|---|---|
| 0x8245DA44 | γ-D-A (sub_8245D9D8) | 0x824AA2F0 (NtSetEvent) | 5 | 23 | 22% |
| 0x8245DB08 | γ-D-B (sub_8245DA78) | 0x824AA2F0 (NtSetEvent) | 1 | 8 | 12% |
| 0x8245DC5C | γ-DB40 (sub_8245DB40) | 0x824AAF50 (Ke wrapper) | 75 | 461 | 16% |
| **TOTAL tid=5/tid=10 signaler work** | | | **81** | **492** | **16%** |
**Headline divergence**: ours completes ~16% of canary's producer-loop iterations.
Not (only) "wrong handles" — ours produces FAR fewer signals.
## Per-LR position-aligned sequence (handle = r3)
Note: ours uses normal slot-id namespace (0x10xx). canary uses pseudo-handle namespace (F8000xxx).
Handles cannot be compared by raw ID. Compare by position-in-per-LR-sequence and by call-args (size r5).
### γ-DB40 dispatch (lr=0x8245DC5C) — Ke wrapper @ 0x824AAF50
Args: r3=handle, r4=buf_ptr, r5=size, r6=0
| pos | ours r3 | ours r5(size) | ours r4(buf) | canary r3 | canary r5(size) | canary r4(buf) |
|---:|---|---|---|---|---|---|
| 0 | 0x00001040 | 0x00000800 | 0x41a01cd0 | 0xf8000030 | 0x00000800 | 0xbdb18cd0 |
| 1 | 0x0000105c | 0x00000800 | 0x41a01cd0 | 0xf8000034 | 0x00000800 | 0xbdb19cd0 |
| 2 | 0x00001098 | 0x00019000 | 0x42c12090 | 0xf8000044 | 0x00000800 | 0xbdb19cd0 |
| 3 | 0x000010ac | 0x00000800 | 0x41a01cd0 | 0xf8000044 | 0x00019000 | 0xbed2a090 |
| 4 | 0x000010d0 | 0x0001c000 | 0x431520d0 | 0xf8000078 | 0x0001c000 | 0xbf26a0d0 |
| 5 | 0x000010e0 | 0x00020000 | 0x4c946800 | 0xf8000078 | 0x00000800 | 0xbdb19cd0 |
| 6 | 0x000010e0 | 0x00020000 | 0x4c966800 | 0xf8000078 | 0x00020000 | 0xb2cb0800 |
| 7 | 0x000010e0 | 0x00020000 | 0x4c986800 | 0xf8000078 | 0x00020000 | 0xb2cd0800 |
| 8 | 0x000010e0 | 0x00020000 | 0x4c9a6800 | 0xf8000078 | 0x00020000 | 0xb2cf0800 |
| 9 | 0x000010e0 | 0x00020000 | 0x4c9c6800 | 0xf8000078 | 0x00020000 | 0xb2d10800 |
| 10 | 0x000010e0 | 0x00020000 | 0x4c9e6800 | 0xf8000078 | 0x00020000 | 0xb2d30800 |
| 11 | 0x000010e0 | 0x00020000 | 0x4ca06800 | 0xf8000078 | 0x00020000 | 0xb2d50800 |
| 12 | 0x000010e0 | 0x00020000 | 0x4ca26800 | 0xf8000078 | 0x00020000 | 0xb2d70800 |
| 13 | 0x000010e0 | 0x00020000 | 0x4ca46800 | 0xf8000078 | 0x00020000 | 0xb2d90800 |
| 14 | 0x000010e0 | 0x00020000 | 0x4ca66800 | 0xf8000078 | 0x00020000 | 0xb2db0800 |
| 15 | 0x000010e0 | 0x00020000 | 0x4ca86800 | 0xf8000078 | 0x00020000 | 0xb2dd0800 |
| 16 | 0x000010e0 | 0x00020000 | 0x4caa6800 | 0xf8000078 | 0x00020000 | 0xb2df0800 |
| 17 | 0x000010e0 | 0x00020000 | 0x4cac6800 | 0xf8000078 | 0x00020000 | 0xb2e10800 |
| 18 | 0x000010e0 | 0x00020000 | 0x4cae6800 | 0xf8000078 | 0x00020000 | 0xb2e30800 |
| 19 | 0x000010e0 | 0x00020000 | 0x4cb06800 | 0xf8000078 | 0x00020000 | 0xb2e50800 |
... (ours total 75, canary total 461)
### γ-D-A dispatch (lr=0x8245DA44) — NtSetEvent wrapper @ 0x824AA2F0
Args: r3=handle, r4=2(SignalKind=Set), r5=handle (dup), r6=ctx
| pos | ours r3 | ours r4 | canary r3 | canary r4 |
|---:|---|---|---|---|
| 0 | 0x00001054 | 0x00000002 | 0xf8000044 | 0x00000002 |
| 1 | 0x00001064 | 0x00000002 | 0xf8000048 | 0x00000002 |
| 2 | 0x000010a0 | 0x00000002 | 0xf8000074 | 0x00000002 |
| 3 | 0x000010b4 | 0x00000002 | 0xf8000080 | 0x00000002 |
| 4 | 0x000010ec | 0x00000002 | 0xf8000098 | 0x00000002 |
| 5 | --- | --- | 0xf80000a8 | 0x00000002 |
| 6 | --- | --- | 0xf80000b8 | 0x00000002 |
| 7 | --- | --- | 0xf80000c4 | 0x00000002 |
| 8 | --- | --- | 0xf80000d4 | 0x00000002 |
| 9 | --- | --- | 0xf80000e0 | 0x00000002 |
| 10 | --- | --- | 0xf80000e8 | 0x00000002 |
| 11 | --- | --- | 0xf80000f0 | 0x00000002 |
| 12 | --- | --- | 0xf80000f8 | 0x00000002 |
| 13 | --- | --- | 0xf80000fc | 0x00000002 |
| 14 | --- | --- | 0xf80000c4 | 0x00000002 |
| 15 | --- | --- | 0xf800009c | 0x00000002 |
| 16 | --- | --- | 0xf80000d4 | 0x00000002 |
| 17 | --- | --- | 0xf80000d4 | 0x00000002 |
| 18 | --- | --- | 0xf80000d4 | 0x00000002 |
| 19 | --- | --- | 0xf80000d0 | 0x00000002 |
| 20 | --- | --- | 0xf80000d0 | 0x00000002 |
| 21 | --- | --- | 0xf80000d0 | 0x00000002 |
| 22 | --- | --- | 0xf8000124 | 0x00000002 |
... (ours total 5, canary total 23)
### γ-D-B dispatch (lr=0x8245DB08) — NtSetEvent wrapper @ 0x824AA2F0
| pos | ours r3 | ours r4 | canary r3 | canary r4 |
|---:|---|---|---|---|
| 0 | 0x000010d8 | 0x7116fc40 | 0xf8000044 | 0x7033fc10 |
| 1 | --- | --- | 0xf8000080 | 0x7033fc10 |
| 2 | --- | --- | 0xf80000c0 | 0x7033fc10 |
| 3 | --- | --- | 0xf80000d0 | 0x7033fc10 |
| 4 | --- | --- | 0xf80000b4 | 0x7033fc10 |
| 5 | --- | --- | 0xf80000d4 | 0x7033fc10 |
| 6 | --- | --- | 0xf80000d0 | 0x7033fc10 |
| 7 | --- | --- | 0xf80000c8 | 0x7033fc10 |
## First-mismatch identification
Per-LR position 0:
- γ-DB40 pos[0]: ours r3=0x1040 r5=0x800 r4=0x41a01cd0 | canary r3=0xF8000030 r5=0x800 r4=0xBDB18CD0
- **r5 (size) MATCHES** = 0x800.
- r4 (buf pointer) DIFFERS in absolute address (0x41a01cd0 vs 0xBDB18CD0) — different memory layouts, expected.
- r3 different namespace — to be expected (pseudo-handle vs slot id).
- γ-D-A pos[0]: ours r3=0x1054 r4=0x2 | canary r3=0xF8000044 r4=0x2
- r4 (signal-kind=Set) MATCHES.
- Args structurally match.
- γ-D-B pos[0]: ours r3=0x10D8 r4=0x7116FC40 r5=0x2 | canary r3=0xF8000044 r4=0x7033FC10 r5=0x2
- r5 (signal-kind) MATCHES.
- r4 (ctx pointer) DIFFERS in absolute address — different stack layout.
Position-0 invocations are STRUCTURALLY consistent. The divergence in per-fire COUNT (5 vs 23, 1 vs 8, 75 vs 461) means ours's producer LOOP runs ~5× fewer iterations before exiting.
## Wedge handle status in ours
**AUDIT-062 archive** (~9 days old) recorded ours wedge handles `0x12AC` and `0x12B8` (kind=Event/Auto)
with `<NO_SIGNALS_DESPITE_WAITS>` annotation.
In THIS run's ours lr-trace: handle 0x12AC count = **0**, handle 0x12B8 count = **0**.
Max handle seen in lr-trace: 0x121C (cache file handle).
The wedge handles `0x12AC`/`0x12B8` were NOT created in this 5B-instruction run — boot terminates early.
## Boot-termination evidence
- ours exec completed 1.5B instr / 47s wallclock, OR 5B instr / 159s wallclock — same handle universe.
- `--halt-on-deadlock` did NOT trigger.
- import_calls = 39,290 identical on both runs.
- tid=5 producer fires 81 events then goes quiet; consumer threads remain blocked on existing handles indefinitely.
- Wedge `0x12AC`/`0x12B8` from AUDIT-062 archive likely formed in deeper-boot trajectory (NtCreateEvent calls after a graphics-frame-tick or similar event that doesn't fire here).
## Classification: missing-signal vs race
**ours produces 81 signals where canary produces 492 from the SAME caller chain on the SAME guest thread.**
This is a **producer-loop-underrun** classification:
- The signaler thread (tid=5) runs the EXACT SAME guest-code path (PCs match, LRs match).
- Position-0 args match structurally.
- But the loop ITERATES far fewer times before going idle.
The "wrong handles" framing from AUDIT-062 is partial: the bigger problem is that **the loop exits early** — most of the work that canary completes never gets touched by ours.
Mechanism: sub_82450A68 dispatch loop reads work from a guest-memory work queue. Each iteration enqueues a new task once the previous fires. If the producer FEEDING that queue under-fires, the dispatch loop's read-head reaches the tail early and the loop exits (or blocks on a dispatcher event with no pending work).
Reference in New Issue View Git Blame Copy Permalink