swift build + test (macOS) crashes 3/3 on fix/910-thrusections-generatedface-guard's CI runner, 0/7 locally — CI-environment-specific, unresolved

[gsdali]

What & why

Investigated during PR #912's round-2 review response (#910). Not root-caused — filing to record
the evidence rather than let a real, reproducible-on-CI signal drop silently, since swift build + test (macOS) is not a required check (only gate-scripts is) and didn't block that PR's merge.

swift build + test (macOS) on fix/910-thrusections-generatedface-guard (commit 115f17a, the
round-2 fix) failed 3/3 CI reruns with the same crash class: two simultaneous, uncaught
SIGSEGVs per run —

*** Abort *** an exception was raised, but no catch was found.
	... The exception is: SIGSEGV 'segmentation violation' detected. Address <large heap address>.
*** Abort *** an exception was raised, but no catch was found.
	... The exception is: SIGSEGV 'segmentation violation' detected. Address 10.

(Address 10 reported identically across two of the three runs; the third reported Address 20.
The large-address crash's value differs each run, consistent with a heap address rather than a
fixed offset.)

Investigation performed

• Round 1 (7b0abee)'s own CI run of the same job passed cleanly — the crash only appeared on
  round 2's commit.
• Test-name correlation was investigated and found too weak to draw a conclusion from. The
  tests reported as "started" nearest the crash differed between the three runs (unrelated
  face/section/pocket tests in run 1; a cluster including "Loft polar-method SIGSEGV regression
  (Modelling ops (loft/ThruSections) SIGSEGV on degenerate profiles; OCC_CATCH_SIGNALS is a no-op without OCC_CONVERT_SIGNALS (#175 follow-up) #176)" in runs 2 and 3) — initially looked suggestive since that suite name references a past
  BRepOffsetAPI_ThruSections crash and this PR touches that same class, but on closer inspection
  Swift Testing dispatches a target's entire test list (~6800+ tests) as "started" almost
  immediately on process launch, so nearly everything sits in that state at any given instant —
  it does not specifically identify what was actually executing concurrently at crash time. None
  of this PR's own new/changed tests (generatedFaceIsMemberOfShapeAfterSuccessFailureSuccess...,
  shapeNilAfterSettingChangedWithoutRebuild, etc.) ever reported a pass OR a fail before any of
  the three crashes — they were queued, not confirmed executing.
• Control comparison: reran main's most recent CI run (unrelated to this PR) twice on the
  same day, same job, same runner pool — 2/2 clean.
• Local reproduction attempted 7 times (OCCTSWIFT_LOCAL=1 swift test, full suite, same commit
  as the 3 failing CI runs) — 7/7 clean, 5537/5537 tests each run, ~55-65s each, no crashes,
  no exceptions.

Net evidence

	Result
main control (CI, same day)	2/2 clean
This branch (CI)	3/3 crashed, same signature
This branch (local, identical commit)	7/7 clean

This is not general infra flakiness (the control rules that out) and not a deterministic logic bug
reproducible locally (7 clean local runs on the exact commit that crashed 3/3 on CI rules that out
too). The two-simultaneous-SIGSEGV shape, with one crash at a small, near-repeatable address, is
the same general signature this project's docs/thread-safety.md/CLAUDE.md "Known OCCT Bugs"
history associates with unsynchronized shared/global OCCT state (#298, #341, #344, #349, #353,
#374) — several of those were found by exactly this mechanism (a PR's new test coverage
concurrently exercising an OCCT class for the first time in a way that surfaces a latent race).
This PR's round 2 added two new tests that exercise BRepOffsetAPI_ThruSections more heavily
under Swift Testing's parallel execution than before (build → fail → build again on a reused
instance, and setter changes between builds) — a plausible but unconfirmed trigger, not
established. CI's runner has meaningfully fewer cores than the local dev machine this was
investigated on, which would explain reproducing there and not locally if the mechanism is
timing/scheduling-window-dependent.

Not done here

• No TSan investigation — this needs the project's established minimal-module TSan protocol
  (see Scripts/tsan-stress.sh and the #298/#341/etc. write-ups this project already has) to
  actually localize a race, if that's what this is. That's a real time investment and out of scope
  for a review-response cycle on an unrelated PR.
• Root cause not identified. This issue exists to hold the evidence, not to claim a diagnosis.

Scope note

Related to, but broader than, #342 (bridge thread contract, open, project-wide) — filing standalone
rather than as a sub-issue since the root cause isn't established and could turn out to be
unrelated to that thread. Cross-referencing it there.

[github-actions]

This issue is missing a type:* label (e.g. type:bug, type:feature, type:chore, type:epic, type:spike, type:docs) and a priority:* label (priority:P0–priority:P3). Please add the appropriate label so it shows up correctly in triage.

[gsdali]

Fourth CI run on this branch (commit f3efeb8), one more data point: same crash class (uncaught SIGSEGV, process abort, no test assertion failures), and the same test cluster ("Loft polar-method SIGSEGV regression (#176)", "Curve3D.extrema... (#636)", "Mesh face indices... (#613)", fillet Add() refuses, OCAF transaction abort tests) reported as recently-started right before the crash — now 3 of 4 observed crashes land near this same cluster, not just 2 of 3 as noted in the original writeup. Recording for whoever picks this up; not re-opening the investigation here per this being a non-blocking, already-filed issue.

[gsdali]

Another occurrence, this time on PR #918 (the clang-format compliance work) — same double-SIGSEGV signature, but in a genuinely DIFFERENT test cluster (mesh/pocket/AAGNode tests) than every prior occurrence (which all clustered around Loft polar-method/Curve3D.extrema/fillet Add()/OCAF transaction tests). Confirms this isn't tied to any specific test region — same crash class showing up wherever the parallel suite happens to be when it hits, consistent with a general resource/timing issue under CI's parallel execution rather than a defect in any specific code path. swift build itself completed cleanly (43.05s, no errors) both times — purely a runtime crash during swift test, not a compile issue. Still not investigating further per this issue's own scope; recording for whoever eventually picks it up.

[gsdali]

Root cause found and fixed

The trigger: generatedFaceIsMemberOfShapeAfterSuccessFailureSuccessOnReusedBuilder (added in PR
#912's round 2, Tests/OCCTStressTests/StressBuilderLifecycleTests.swift) unintentionally
constructs the exact crash trigger #913/patch 0027 fixes, unguarded.

The chain

1. Package.swift's remote pin — what ci.yml's swift build + test (macOS) job actually
   resolves, and what any fresh checkout with no local Libraries/ gets by default — is the
   v2.0.0 release asset: OCCT V8_0_1 + only the fifteen patches that existed when that release
   was cut (0010-0012, 0014-0025). Scripts/patches/ on main now has seventeen
   (0010-0027) — 0026 (ThruSectionsBuilder(isSolid: true) silently omits both end caps for a non-planar closed section wire (k >= 2 out-of-plane periods) #905) and 0027 (ThruSectionsBuilder checkCompatibility(false) + mismatched section edge counts SIGSEGVs on a reused builder #913) both landed after the release and are only
   applied by kernel-integration.yml's from-source rebuild, never by ci.yml.
2. Patch 0027 fixes a confirmed heap-corruption bug: BRepOffsetAPI_ThruSections::CreateSmoothed()
   derives the edge count it assumes every section has from section 1 alone, and fills a
   fixed-stride array on that assumption with no bounds check. A later section with more
   edges than section 1 overruns the array. Without checkCompatibility(true)'s reconciliation
   (i.e. under checkCompatibility(false)), nothing catches the mismatch first.
3. generatedFaceIsMemberOfShapeAfterSuccessFailureSuccessOnReusedBuilder's own "build B" step is
   exactly this: checkCompatibility(false), then a 4th section (a triangle, 3 edges) added after
   three single-edge circles — a later section with more edges than section 1, checkCompatibility
   disabled, 4 sections total. This test runs, unguarded, in every default swift test invocation.
4. On the unpatched kernel this doesn't always crash outright — heap corruption is nondeterministic.
   Sometimes it silently produces a wrong answer (build() returns true instead of false, as I
   measured directly below); sometimes it corrupts memory that a later, unrelated test's
   allocation reuses, producing an uncatchable SIGSEGV in whatever part of the parallel suite
   happens to touch it next — exactly matching every occurrence recorded on this issue: different
   test cluster each time, no way to attribute from the crashing test's own name.

This also fully explains why every single one of my ~10 local reproduction attempts came back
clean: OCCTSWIFT_LOCAL=1 (which I used throughout, and which is also the default behavior
whenever a local Libraries/OCCT.xcframework is present — this worktree has had one since earlier
kernel-rebuild work) resolves the locally-rebuilt kernel, which has all seventeen patches including
0027. I was never testing the same kernel CI actually uses.

Measured, not assumed

Forced the exact remote kernel with OCCTSWIFT_REMOTE=1 (overriding the local-directory
auto-detection) and ran the suspect test directly:

OCCTSWIFT_REMOTE=1 swift test --filter generatedFaceIsMemberOfShapeAfterSuccessFailureSuccessOnReusedBuilder

✘ StressBuilderLifecycleTests.swift:591: Expectation failed: !(loft.build() → true)
✘ StressBuilderLifecycleTests.swift:592: Expectation failed: (loft.generatedFace(from: edge)) == nil
✘ StressBuilderLifecycleTests.swift:598: Expectation failed: loft.build()

build() on "build B" returned true instead of failing cleanly — matching #913's own "silently
misaligned... reporting build() == true for an invalid result" description precisely. No other
file in the test suite uses checkCompatibility(false) at all (checked directly), so this is the
sole trigger.

Fix

Gated the test behind OCCTSWIFT_LOCAL, the exact same mechanism and reasoning already
established for #913's own equally-dangerous test (mismatchedSectionEdgeCountWithoutCheckFailsCleanly,
gated since PR #915's own review found this exact class of danger for that test). Verified:
OCCTSWIFT_REMOTE=1 now correctly skips it; OCCTSWIFT_LOCAL=1 still runs and passes it.
Full suite run 6x against the forced remote kernel (OCCTSWIFT_REMOTE=1 swift test, matching CI's
resolution exactly) — clean every time (in progress at time of writing, will report final count).

Filed as a standalone PR (not bundled into #918) since this blocks CI broadly, not just one PR.

Duplicate #922 closed, cross-referenced here — its patch-count observation was the key clue that
cracked this.

[gsdali]

Fixed and merged via #924 (e1b75ae). Confirmed on real CI, not just local forced-remote-kernel runs: swift build + test (macOS) — the exact job that had crashed across #915, #918, and #921 — passed cleanly with the fix applied. Closing.