xenia-rs/audit-runs/audit-069-wait-signal-producer/s3/handle-sequence-diff.md

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).