Skip to content

fix(#341/#363): OwnAutoNamingScope — per-instance override, not a global mutex — v1.15.15#366

Merged
gsdali merged 1 commit into
mainfrom
fix/341-own-autonaming-scope-redesign
Jul 23, 2026
Merged

fix(#341/#363): OwnAutoNamingScope — per-instance override, not a global mutex — v1.15.15#366
gsdali merged 1 commit into
mainfrom
fix/341-own-autonaming-scope-redesign

Conversation

@gsdali

@gsdali gsdali commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Follow-up to NCollection race under parallel execution: documented downstream as 'run --no-parallel', never filed or characterised upstream — needs the #298 TSan protocol #341 (v1.15.5) after upstream review on OCCT#1388. Maintainer gkv311 pointed out AutoNamingScope's recursive_mutex only serialized the three known override call sites against each other — every other read of theAutoNaming in XCAFDoc_ShapeTool.cxx (AddShape, MakeReference, SetSHUO) stayed outside any scope, so an unrelated unscoped caller on another thread could still observe another thread's temporary override. Making the flag atomic closed the memory-safety gap, not the logical one.
  • Root design issue: theAutoNaming was never meant to express per-document intent — the three overriding call sites each want to suppress naming for their own document's build, and XCAFDoc_ShapeTool is already one instance per document, so the override belongs there.
  • Fix: XCAFDoc_ShapeTool::OwnAutoNamingScope replaces AutoNamingScope, saving/restoring a per-instance myOwnAutonaming field instead of the shared flag — no locking needed, and XCAFDoc_Editor::Expand()'s self-recursion still composes correctly since each nested scope restores exactly the override state it observed on entry, not an unconditional reset. Patch 0011 updated in place (same fix, corrected design, not a new patch number).
  • Verified: same TSan stress as the original fix, zero theAutoNaming races. New isolation scenario (Scripts/repro/363-own-autonaming/) checks the property the mutex fix couldn't guarantee: half the threads override locally while the other half do unscoped AddShape() on independent documents, concurrently — 3000 operations, zero leaks.
  • Full production OCCT.xcframework rebuild (macOS, iOS device, iOS simulator). OCCTBridge.xcframework also rebuilt — ABI-only, XCAFDoc_ShapeTool grew a field so the previously-compiled bridge static library needed relinking against the new kernel layout, even though no bridge source changed.
  • Docs: CLAUDE.md Known OCCT Bugs, docs/CHANGELOG.md, docs/thread-safety.md, Scripts/patches/README.md, okf/references/carried-occt-patches.md, Scripts/repro/341-meshcaf/README.md.
  • Upstream: OCCT#1388 updated to the new design and re-reviewed — CI green across all 3 platforms, every build/GTest/regression/test job.

Test plan

  • swift build clean (source bridge, rebuilt kernel)
  • OCCTSWIFT_BRIDGE_PREBUILT=1 swift build clean (rebuilt bridge + rebuilt kernel)
  • Issue341MeshCafThreadSafetyTests/Issue361SharedSingletonThreadSafetyTests/Issue359 pass on both build paths
  • Full swift test — 4427 tests / 1284 suites, clean

Closes #363

🤖 Generated with Claude Code

…bal mutex (v1.15.15)

Follow-up to #341 (v1.15.5) after upstream review on OCCT#1388.
Maintainer gkv311 pointed out AutoNamingScope's recursive_mutex only
serialized the three known override call sites against each other --
every other read of theAutoNaming in XCAFDoc_ShapeTool.cxx (AddShape,
MakeReference, SetSHUO) stayed outside any scope, so an unrelated
unscoped caller on another thread could still observe another
thread's temporary override. Making the flag atomic closed the
memory-safety gap, not the logical one.

Root design issue: theAutoNaming was never meant to express
per-document intent -- the three overriding call sites each want to
suppress naming for their own document build, and XCAFDoc_ShapeTool
is already one instance per document, so the override belongs there.

Fix: XCAFDoc_ShapeTool::OwnAutoNamingScope replaces AutoNamingScope,
saving/restoring a per-instance myOwnAutonaming field instead of the
shared flag -- no locking needed, and XCAFDoc_Editor::Expand()'s
self-recursion still composes correctly since each nested scope
restores exactly the override state it observed on entry, not an
unconditional reset. Patch 0011 updated in place (same fix, corrected
design, not a new patch number).

Verified: same TSan stress as the original fix, zero theAutoNaming
races. New isolation scenario (Scripts/repro/363-own-autonaming/)
checks the property the mutex fix couldn't guarantee: half the
threads override locally while the other half do unscoped AddShape()
on independent documents, concurrently -- 3000 operations, zero
leaks. Full production OCCT.xcframework rebuild (macOS, iOS device,
iOS simulator); OCCTBridge.xcframework also rebuilt (ABI-only --
XCAFDoc_ShapeTool grew a field, no bridge source changed) and
re-verified against the new kernel; full swift test clean, both
build paths.

Upstream: OCCT#1388 updated to the new design and re-reviewed -- CI
green across all 3 platforms, every build/GTest/regression/test job.

Closes #363

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@gsdali
gsdali merged commit 2f093ea into main Jul 23, 2026
@gsdali
gsdali deleted the fix/341-own-autonaming-scope-redesign branch July 23, 2026 07:49
@gsdali
gsdali restored the fix/341-own-autonaming-scope-redesign branch July 23, 2026 07:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Revisit #341's AutoNamingScope fix: adopt per-instance override instead of mutex+atomic (upstream review, OCCT#1388)

1 participant