Skip to content

v1.15.4 — fix #341: OBJ/glTF/PLY CAF import race

Choose a tag to compare

@gsdali gsdali released this 21 Jul 10:49
466f3ff

v1.15.4 — fix: concurrent OBJ/glTF/PLY import races on an unsynchronized OCCT global; the "NCollection race" claim doesn't hold up (#341)

Applied the #298 TSan protocol to the long-standing, never-filed "pre-existing non-deterministic
NCollection arm64 race under parallel execution" claim (carried since ~v0.51.0, backing
swift test --no-parallel and three permanently-.disabled() stress suites). No NCollection race
reproduces at any tested scale.
Re-enabled the three suites — 25/25 clean runs.

Found instead: RWMesh_CafReader::fillDocument() (shared base of RWObj_CafReader/
RWGltf_CafReader — OBJ and glTF import, plus PLY export via AddShape) saves/mutates/restores
the process-global XCAFDoc_ShapeTool::theAutoNaming with zero synchronization. Same failure class
as #298. Every OBJ/glTF/PLY bridge call now serializes on a dedicated meshCafMutex(). Minimal TSan
reproducer: Scripts/repro/341-meshcaf/. Filed upstream:
Open-Cascade-SAS/OCCT#1387.

Binary releaseOCCTBridge.xcframework (opt-in prebuilt bridge, #339) rebuilt with the fix;
OCCT.xcframework unchanged. See docs/CHANGELOG.md for the full writeup.