Repository navigation
Give ported objects an HVO from the target cache, so a copied cache never shares an HVO between two objects - #405
Open
johnml1135 wants to merge 2 commits into
Conversation
…nique Copying a cache whose objects are only partly activated currently carries the source cache's HVOs onto dormant objects in the target, where the target's own HVO counter hands the same numbers out again. This test fails until the copy gives each object an HVO from the target cache. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When a cache is copied with InitializeFromSource, dormant source objects kept the HVO their CmObjectIdWithHvo had in the source cache. The target never reserved those numbers, so its own HVO counter handed them out again to activated or newly created objects, and GetObject(hvo) could return the wrong object. The cross-cache surrogate constructor now always takes a new id from the target identity map, as already happened for activated sources. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A cache copied with
InitializeFromSource/LcmCache.CreateCacheCopycan give two objects the same HVO, soGetObject(hvo)returns the wrong object. This one-line fix gives every ported object an HVO from the target cache. No schema, model version, persisted field or file format changes.What goes wrong. The cross-cache
CmObjectSurrogate(LcmCache, ICmObjectSurrogate)constructor keeps the source surrogate'sCmObjectIdWithHvo. Registering that surrogate as inactive does not reserve the number in the target, and the target's allocator starts at 1. So objects activated or created in the copy are handed numbers that dormant ported objects already carry, andm_extantObjectsByHvo[hvo]is overwritten. A source that was fully activated before copying is unaffected, which is why callers today work around this by activating every object first. On large projects that costs seconds.The fix. The constructor always takes an id from the target identity map (
CreateObjectIdWithHvo(guid)), as already happened for activated sources.Tests.
BEPPortTests.PortFromPartlyActivatedSourceGivesMemoryOnlyTargetUniqueHvos, in its own commit before the fix. It fails without the fix (HVOs shared … 2 (2 objects), 4 (2 objects) …) and passes with it.SIL.LCModel.Testsnet8.0 on this branch: 1,717 passed, 0 failed, 18 skipped. Before and after the fix on the earlier base, the full net8.0 suites (Core, Utils, FixData) were otherwise unchanged. net462 was not run.Evidence from a downstream consumer (Motif)
GetObjectlookups across five activation patterns. After the fix: none.Related, not fixed here:
AUnialternatives in a writing system the cache does not yet know are dropped on activation, depending on activation order. Filed separately.🤖 Generated with Claude Code
This change is