jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Correct placed-structure restore owner split

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 23:57:27 -07:00
commit 8d5fb4f02f
2 changed files with 65 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

50
crates/rrt-runtime/src/smp.rs
View file

@ -4756,8 +4756,9 @@ fn build_periodic_company_service_trace_report(
"[site+0x276] live owner-company meaning is grounded through 0x0047efe0 / 0x0040d210".to_string(),
"[site+0x2a4] self-id meaning is grounded through 0x0041f7e0 / 0x0041f810 / 0x0041f850".to_string(),
"0x004269b0 resolves the chosen site id through placed-structure collection 0x0062b26c before mutating the live row, so [site+0x2a4] is reconstructible from collection identity rather than a separate serializer-owned selector".to_string(),
"0x00444690 -> 0x004133b0 -> 0x0040ee10 is the current checked-in replay family above live placed structures".to_string(),
"0x00444690 -> 0x004133b0 -> 0x0040ee10 is the current checked-in ordinary bring-up replay family above live placed structures".to_string(),
"0x004133b0 rebuilds cloned local-runtime records through 0x0040e450 and 0x0040ee10 only republishes local position/scalar triplets before 0x0040e360".to_string(),
"the ordinary bring-up strip stays separate from the constructor/finalize family too: after 0x00444690 -> 0x004133b0 the world restore continues through later route-entry/grid/tagged refresh owners rather than re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".to_string(),
"direct local replay-strip inspection now splits that family more precisely: bounded 0x0040ee10 itself only reads cached source lane [site+0x3cc], and the bounded 0x00480710 neighborhood is working from [site+0x04], [site+0x08], and [site+0x3cc]; the broader immediate continuation 0x0040e360..0x0040edf6 still consumes [site+0x2a8], [site+0x2a4], and [site+0x276] around 0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860, but in the checked range those [site+0x276] uses are still reads/queries rather than a direct rehydrating store".to_string(),
"direct constructor control-flow now shows 0x004134d0 allocating a new placed-structure row through 0x00518900 and then calling 0x0040f6d0, which seeds [site+0x2a4], clears broad row state, copies the display name bytes, and writes [site+0x276] from an incoming argument before any later service logic runs".to_string(),
"0x0040f6d0 immediately zeroes [site+0x2a8/+0x272/+0x27a/+0x29e], stamps [site+0x3d4/+0x3d5], and seeds further local caches, which makes it a create-side initializer rather than a replay-only refresh".to_string(),
@ -4769,7 +4770,8 @@ fn build_periodic_company_service_trace_report(
"the remaining 0x00508fd1 / 0x005098eb strip is bounded away from persisted restore too: 0x00508fd1 stores the new row id in [this+0x7c], immediately configures the live row through vtable slot +0x58 plus 0x00507cf0, and 0x005098eb later re-enters 0x0040ef10 with arg3 forced to zero, so this family is another live controller path rather than the missing persisted owner seam".to_string(),
"the adjacent 0x00473c20 family is bounded away too: it drains queued site ids and coordinate pairs from scratch band 0x006ce808..0x006ce988, re-enters 0x0040eba0 at 0x00473c98 for each live row, and then clears the queued id slot, so it is a local post-create refresh path rather than the missing persisted owner seam".to_string(),
"the remaining direct [site+0x276] store census is bounded away too: 0x0042128d is broad zero-init in the 0x00421430 constructor neighborhood, 0x00422305 computes a live score/category lane before publishing event 0x7, 0x004269c9/0x00426a2a are acquisition commit and clear helpers, and 0x004282a9 / 0x004300d6 are bulk owner-transfer writes rather than ordinary restored-row replay".to_string(),
"the paired collection-side load owner 0x00413440 is bounded away too: it opens tagged families 0x36b1 / 0x36b2 / 0x36b3, routes each live record through per-entry vtable slot +0x44, and keeps that seam on the already-grounded triplet payload/load-save strip rather than the missing [site+0x276] replay owner".to_string(),
"the paired collection-side serializer 0x00413440 is bounded away too: it opens tagged families 0x36b1 / 0x36b2 / 0x36b3 on the save side, routes each live record through per-entry vtable slot +0x44, and keeps that seam on the already-grounded triplet payload/load-save strip rather than the missing [site+0x276] replay owner".to_string(),
"the actual broader restore-side stream-load owner remains 0x00413280: it opens tagged 0x36b1 / 0x36b2 / 0x36b3 on the load side, dispatches per-entry vtable slot +0x40, and currently only grounds the cached-source bridge 0x0040ce60 -> 0x0040cd70 / 0x0045c150 rather than a direct [site+0x276] republisher".to_string(),
"inside 0x0040ef10 the [site+0x276] write at 0x0040f047 only clears owner-company under a world-flag branch, while the paired [site+0x276]/[site+0x27a] write at 0x0040f5d4 follows a 0x00436590 event/scalar path and is not the generic post-load republisher".to_string(),
"direct local writer census now shows the grounded [site+0x276] write side clustering under live mutation families such as 0x004269b0 / 0x00426a10, the create-side 0x0040ef10 / 0x0040f6d0 strip, and the bulk reassignment families 0x00426dce..0x00426ea1 and 0x00430040..0x004300d6 rather than under the known replay strip".to_string(),
"direct local control-flow reconstruction now shows those same writer families hanging under the 0x00431b20 opcode dispatcher over 0x0061039c: opcodes 0x04..0x07 dispatch to 0x00430040, opcodes 0x08/0x10..0x13 dispatch to 0x00426d60, and opcodes 0x0d/0x16 dispatch to 0x0042fc90".to_string(),
@ -4778,7 +4780,8 @@ fn build_periodic_company_service_trace_report(
blockers: vec![
"current atlas evidence now grounds one tuple-backed owner path too: loader tuple field [+0x0c] reaches [site+0x276] through 0x0046f073 / 0x004707ff -> 0x0040ef10, but the classified 0x004707ff caller belongs to multiplayer transport selector-0x13 rather than ordinary save-load restore, so a non-transport persisted source family is still needed for shellless acquisition".to_string(),
"the explicit store census now also rules down the remaining obvious non-transport writes, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families".to_string(),
"the paired collection-side triplet load owner 0x00413440 is ruled down too, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families and the tagged 0x36b1/0x36b2/0x36b3 load path".to_string(),
"the paired collection-side triplet serializer 0x00413440 is ruled down too, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families and the tagged 0x36b1/0x36b2/0x36b3 load-save strip".to_string(),
"the load-side stream owner 0x00413280 is ruled down to cached-source/candidate replay through vtable slot +0x40 and 0x0040ce60, so the missing ordinary restored-row owner seam still sits beyond the current stream-load bridge too".to_string(),
],
},
SmpServiceConsumerHypothesis {
@ -4943,7 +4946,7 @@ fn build_periodic_company_service_trace_report(
"0x00422305 live score/category publisher writing [site+0x276] before event 0x7 dispatch, not ordinary restore".to_string(),
"0x004269c9 / 0x00426a2a acquisition commit and clear helpers mutating [site+0x276]/[site+0x27a] on chosen live rows".to_string(),
"0x004282a9 / 0x004300d6 bulk owner-transfer writes over existing live placed-structure rows".to_string(),
"0x00413440 paired tagged 0x36b1/0x36b2/0x36b3 collection loader dispatching each live record through vtable slot +0x44".to_string(),
"0x00413440 paired tagged 0x36b1/0x36b2/0x36b3 collection serializer dispatching each live record through vtable slot +0x44".to_string(),
"0x004134d0 / 0x0040ef10 shared placed-structure allocator and finalize-or-rebuild lane for newly created or tuple-loaded site rows"
.to_string(),
"0x00481430 / 0x0047d8e0 dynamic side-buffer stream-load owner repopulating route-entry lists, three byte arrays, five proximity buckets, and trailing scratch band"
@ -28478,6 +28481,20 @@ mod tests {
.iter()
.any(|line| line.contains("0x0046f073 / 0x004707ff"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x00444690 -> 0x004133b0")
&& line.contains("ordinary bring-up replay family"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("after 0x00444690 -> 0x004133b0")
&& line.contains("0x004134d0 / 0x0040f6d0 / 0x0040ef10"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
@ -28590,8 +28607,17 @@ mod tests {
.iter()
.any(|line| line.contains("0x00413440")
&& line.contains("0x36b1 / 0x36b2 / 0x36b3")
&& line.contains("save side")
&& line.contains("slot +0x44"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x00413280")
&& line.contains("slot +0x40")
&& line.contains("0x0040ce60"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
@ -28683,6 +28709,22 @@ mod tests {
.iter()
.any(|line| line.contains("0x0040cd70 cached source/candidate resolver"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.blockers
.iter()
.any(|line| line.contains("0x00413440")
&& line.contains("0x36b1/0x36b2/0x36b3")
&& line.contains("load-save strip"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.blockers
.iter()
.any(|line| line.contains("0x00413280")
&& line.contains("0x0040ce60")
&& line.contains("stream-load bridge"))
);
assert_eq!(
trace
.near_city_acquisition_runtime_backed_input_families

25
docs/rehost-queue.md
View file

@ -200,14 +200,27 @@ Working rule:
`0x00422305` computes a live score/category lane before publishing event `0x7`,
`0x004269c9/0x00426a2a` are acquisition commit/clear helpers, and
`0x004282a9/0x004300d6` are bulk owner-transfer writes
- the paired tagged collection loader is bounded away too:
`0x00413440` owns the tagged `0x36b1/0x36b2/0x36b3` triplet load path, dispatches each live
record through vtable slot `+0x44`, and keeps that seam on the already-grounded triplet
payload rather than the missing `[site+0x276]` replay owner
- the paired tagged triplet serializer is bounded away too:
`0x00413440` is the save-side `0x36b1/0x36b2/0x36b3` serializer, dispatches each live record
through vtable slot `+0x44`, and keeps that seam on the already-grounded triplet payload
rather than the missing `[site+0x276]` replay owner
- the ordinary bring-up strip is narrower too:
`0x00444690 -> 0x004133b0` is still the checked ordinary restore-side replay owner above live
placed structures, but it only drains queued local-runtime ids through `0x0040e450` and then
sweeps live rows through `0x0040ee10`; after that, bring-up proceeds into later route-entry,
grid, and tagged refresh owners rather than re-entering the constructor/finalize family
`0x004134d0 / 0x0040f6d0 / 0x0040ef10`
- the broader load-side stream owner is separate too:
`0x00413280` is the actual tagged `0x36b1/0x36b2/0x36b3` stream-load owner, dispatching
per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the
cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct
`[site+0x276]` republisher
- the remaining owner-company question is therefore narrower than “find any replay seam”:
identify which non-transport persisted source family outside the currently bounded direct
allocator/finalize/store families feeds that tuple and which companion restore/finalize calls
are sufficient to repopulate `[site+0x276]` for shellless acquisition
allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
`0x00413280` cached-source bridge, and the checked ordinary replay strip
`0x00444690 -> 0x004133b0 -> 0x0040ee10` feeds the tuple or companion restore calls that are
sufficient to repopulate `[site+0x276]` for shellless acquisition
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`