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

Tighten placed-structure restore versus finalize split

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 02:13:33 -07:00
commit 72fe1f3a5f
2 changed files with 29 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -4701,7 +4701,7 @@ fn build_periodic_company_service_trace_report(
.to_string(),
];
let near_city_acquisition_site_owner_company_projection_status =
"transport_tuple_owner_arg_grounded_direct_and_triplet_families_bounded_nontransport_restore_source_missing"
"ordinary_replay_ruled_down_stream_load_callback_grounded_tuple_finalize_path_grounded_nontransport_restore_source_missing"
.to_string();
let near_city_acquisition_site_self_id_projection_status =
"live_meaning_grounded_reconstructible_from_collection_identity".to_string();
@ -4755,7 +4755,7 @@ fn build_periodic_company_service_trace_report(
let near_city_acquisition_projection_hypotheses = vec![
SmpServiceConsumerHypothesis {
label: "site_owner_replay_from_post_load_refresh_self_id_reconstructible".to_string(),
status: "local_runtime_replay_ruled_down_constructor_and_finalize_families_bounded".to_string(),
status: "ordinary_replay_and_stream_load_ruled_down_tuple_finalize_positive_path_grounded".to_string(),
candidate_consumers: vec![
"0x00444690 late world bring-up caller".to_string(),
"0x004133b0 placed-structure local-runtime replay owner".to_string(),
@ -4781,8 +4781,8 @@ fn build_periodic_company_service_trace_report(
"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(),
"shared finalize helper 0x0040ef10 now has create-side callers 0x00403ef3 / 0x00404489 and data-driven callers 0x0046f073 / 0x004707ff; the latter feed it from tuple-backed loads after 0x0040eba0 / 0x0052eb90 rather than from the checked-in local replay strip".to_string(),
"the loader-side dataflow is narrower now too: 0x0046f073 / 0x004707ff push tuple fields [+0x00/+0x04/+0x0c] into 0x0040ef10, that helper reads arg3 into ebx at 0x0040ef1c, and the paired write at 0x0040f5d4 stores ebx into [site+0x276] while 0x0040f5da stores the computed companion word into [site+0x27a]".to_string(),
"the outer owner above 0x004707ff is now classified too: atlas-backed recovery ties that caller to multiplayer transport selector-0x13 body 0x004706b0, which attempts the placed-structure apply path through 0x004197e0 / 0x004134d0 / 0x0040eba0 / 0x0052eb90 / 0x0040ef10 rather than ordinary save-load restore".to_string(),
"the loader-side dataflow is narrower now too: 0x0046efbf is the paired constructor call and 0x0046f073 / 0x004707ff are the paired finalize calls in the tuple-backed data path; 0x0046efbf and 0x0047074b both reach 0x004134d0 first, then 0x0046f073 / 0x004707ff push tuple fields [+0x00/+0x04/+0x0c] into 0x0040ef10, that helper reads arg3 into ebx at 0x0040ef1c, and the paired write at 0x0040f5d4 stores ebx into [site+0x276] while 0x0040f5da stores the computed companion word into [site+0x27a]".to_string(),
"the outer owner above 0x0046efbf / 0x0046f073 / 0x0047074b / 0x004707ff is now classified too: atlas-backed recovery ties those calls to multiplayer transport selector-0x13 body 0x004706b0, which attempts the placed-structure apply path through 0x004197e0 / 0x004134d0 / 0x0040eba0 / 0x0052eb90 / 0x0040ef10 rather than ordinary save-load restore".to_string(),
"the neighboring builder strip 0x00472b40 is classified too now: atlas-backed recovery ties it to multiplayer transport selector-0x72, the heavier counted live-world apply path over 0x0062b2fc / 0x0062b26c / 0x0062bae0, and its inner calls 0x00472bef / 0x00472d03 reach 0x004134d0 from counted transport records rather than ordinary save-load restore".to_string(),
"another surviving 0x004134d0 caller is bounded away from persisted restore too: 0x00422bb4 pushes one live 0x0062b2fc record plus local args and literal flags 1/0 into 0x004134d0, then returns the created row id through an out-param rather than re-entering the tuple-backed finalize path".to_string(),
"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(),
@ -4790,6 +4790,7 @@ fn build_periodic_company_service_trace_report(
"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 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(),
"direct local control flow now rules the ordinary bring-up owner down even further: 0x00444690 immediately calls 0x004133b0 and then continues into later grid/world refresh owners without re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".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(),
@ -4805,6 +4806,7 @@ fn build_periodic_company_service_trace_report(
"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 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(),
"the ordinary bring-up caller 0x00444690 is ruled down too: it just enters 0x004133b0 and then proceeds into later refresh owners, so the positive [site+0x276] write side at 0x0040ef10 remains a tuple/create path rather than the checked ordinary restore path".to_string(),
"the checked ordinary restore ordering is ruled down too: 0x00413280 stream load, 0x00481210 dynamic side-buffer refresh, and 0x004133b0 local-runtime replay all sit on the bring-up strip without re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".to_string(),
"the grouped opcode dispatcher 0x00431b20 is still not a tagged restore owner, but the remaining uncertainty is now narrower than compact row framing too: restore-side 0x00433130 with 0x0042db20 reloads compact row bodies into ordinary live event rows in 0x0062be18, nearby 0x0042e050 is the separate full-event copy owner for [event+0x7ee..0x80f], the event-detail editor exposes [event+0x7ef] across 0x00..0x0a including kind 8, and sampled map bundles now decode into concrete grouped descriptors, so the open question is which serialized/live rows feed trigger kind 8 into that control lane and which of those loaded rows can actually reach the placed-structure mutation opcodes under 0x00431b20".to_string(),
],
@ -10856,7 +10858,8 @@ fn parse_real_grouped_effect_row_summary(
row_shape = "scalar_assignment".to_string();
semantic_family = "scalar_assignment".to_string();
}
if descriptor_metadata.is_some_and(|metadata| metadata.parameter_family == "world_building_spawn")
if descriptor_metadata
.is_some_and(|metadata| metadata.parameter_family == "world_building_spawn")
{
row_shape = "building_spawn_batch".to_string();
semantic_family = "building_spawn_batch".to_string();
@ -10904,7 +10907,8 @@ fn parse_real_grouped_effect_row_summary(
));
}
}
if descriptor_metadata.is_some_and(|metadata| metadata.parameter_family == "world_building_spawn")
if descriptor_metadata
.is_some_and(|metadata| metadata.parameter_family == "world_building_spawn")
{
let candidate_id = descriptor_id.saturating_sub(503);
notes.push(format!(
@ -29338,7 +29342,7 @@ mod tests {
);
assert_eq!(
trace.near_city_acquisition_site_owner_company_projection_status,
"transport_tuple_owner_arg_grounded_direct_and_triplet_families_bounded_nontransport_restore_source_missing"
"ordinary_replay_ruled_down_stream_load_callback_grounded_tuple_finalize_path_grounded_nontransport_restore_source_missing"
);
assert_eq!(
trace.near_city_acquisition_site_self_id_projection_status,
@ -29397,7 +29401,7 @@ mod tests {
);
assert_eq!(
trace.near_city_acquisition_projection_hypotheses[0].status,
"local_runtime_replay_ruled_down_constructor_and_finalize_families_bounded"
"ordinary_replay_and_stream_load_ruled_down_tuple_finalize_positive_path_grounded"
);
assert_eq!(
trace.near_city_acquisition_projection_hypotheses[1].label,

17
docs/rehost-queue.md
View file

@ -332,6 +332,23 @@ Working rule:
restore calls that are sufficient to repopulate `[site+0x276]` for shellless acquisition; the
remaining runtime-effect subquestion is now which loaded kind-`8` rows can carry the
placed-structure mutation opcodes rather than whether kind `8` is synthetic
- the ordinary restore-vs-finalize split is tighter now too:
direct disassembly shows `0x00413280` stream-loading `0x36b1/0x36b2/0x36b3` through per-entry
vtable slot `+0x40`, and `0x00444690` simply enters `0x004133b0` before continuing into later
grid/world refresh owners; neither ordinary bring-up owner re-enters
`0x004134d0 / 0x0040f6d0 / 0x0040ef10` for already-restored rows. The positive
`[site+0x276]` store at `0x0040f5d4` therefore remains grounded only on explicit tuple/create
paths, so the next non-hook pass should look for a non-transport persisted tuple family or a
later ordinary restore owner rather than another generic replay scan.
- the positive-path caller census is effectively boxed in now too:
direct `0x0040ef10` callers are the create-side pair `0x00403ef3 / 0x00404489`, the transport
tuple pair `0x0046f073 / 0x004707ff`, and the already-ruled-down live controller
`0x005098eb`; direct `0x004134d0` callers are the create-side pair `0x00403ed5 / 0x0040446b`,
the transport-side pair `0x0046efbf / 0x0047074b`, the counted transport builders
`0x00472bef / 0x00472d03`, plus live/controller callers `0x00422bb4` and `0x00508fd1`.
That means the still-missing owner seam is no longer “find another obvious constructor/finalize
caller”; it is specifically a non-transport persisted tuple family or a later ordinary restore
owner outside this boxed caller set.
- 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]`