DocxReader.read segfaults in debug builds on a deeply nested real document (3.6.4 AND 3.7.0; release builds unaffected)

[kiki830621]

Problem

DocxReader.read in v3.6.4 segfaults on a real Word document in a debug build. The same document reads fine in a release build, and fine in both modes at the PR #141 cluster head (the 3.7.0 candidate).

Reproduction

Document: a Chinese-government review form (REC-O-01-…docx, deeply nested tables). Debug binary:

$ macdoc docx apply manifest.json --input <doc> --output out.docx
exit=139        # SIGSEGV

0  swift_retain + 32 in libswiftCore.dylib
1  static DocxReader.read(from:wireTreeBackedViews:) + 24908
     .build/checkouts/ooxml-swift/Sources/OOXMLSwift/IO/DocxReader.swift
2  Executor.apply(manifest:baselineURL:outputURL:warnHandler:)  (docx-workflow-swift)
3  MacDoc.Docx.Apply.run()

Release build of the same commit: exit 0. That asymmetry is the signature of a stack overflow — debug frames are several times larger — which fits a recursive descent over a deeply nested document.

Not present at the 3.7.0 candidate

A minimal probe against the PR #141 cluster head (001e95a) reads the same file in both modes:

OK tree-backed: body children=7
OK detached:    body children=7

So the reader/IO rework in the 3.7.0 cluster removes it. Whether that was deliberate or incidental is not established here — no test in the suite covers this document, so nothing would notice if it came back.

Why it stayed hidden

macdoc's dependency graph was frozen at v3.2.0 by a branch: "main" pin (macdoc#184). Catching the graph up to 3.6.4 is what surfaced this; before that, macdoc never ran any 3.6.x reader.

Suggested handling

• Add the deep-nesting shape (or this document, minimised) as a reader fixture, so the fix in 3.7.0 is guarded rather than incidental.
• If the mechanism is confirmed as recursion depth, consider an explicit depth bound with a named refusal — the same treatment PackageInspector.stripComments 的 <!--.*?--> 對未閉合 <!-- 呈二次退化——5 KB 的 .docx 讓檢查跑一分鐘（follow-up finding from che-word-mcp#199 verify） #138 gave comment stripping — rather than relying on frame size.

Surfaced while implementing macdoc#184 (dependency catch-up). Refs PsychQuant/macdoc#184

[kiki830621]

Correction — 3.7.0 does NOT fix this

My original report claimed the crash was absent at the 3.7.0 candidate. That claim was wrong, and the evidence I gave for it did not support it.

What I measured, and why it misled me

The probe I ran called DocxReader.read directly from a standalone executable and reported OK for both modes. But macdoc docx apply reaches the reader through Executor.apply, inside swift-argument-parser's async main. Reading the file in isolation is not the same path, and only the full path crashes.

Re-measured against released v3.7.0, same document, same manifest:

debug    exit=139 (SIGSEGV)
release  exit=0

Identical to 3.6.4. The backtrace is unchanged:

0  swift_retain + 32
1  static DocxReader.read(from:wireTreeBackedViews:) + 24908
2  Executor.apply(...)
3  MacDoc.Docx.Apply.run()
6  [async] AsyncParsableCommand.main()

What is established

• Present in 3.6.4 and 3.7.0; absent at the v3.2.0-era pin macdoc used to be frozen on. So it entered somewhere in 3.3.0–3.6.4 and 3.7.0 did not remove it.
• Debug only. Release builds of the same commit are fine — the signature of a stack overflow, since debug frames are several times larger.
• Calling DocxReader.read directly on the main thread does not reproduce it, in debug or release. Something about the call context in Executor.apply (async task stack, or the deeper frame chain below it) is required. I have not isolated which.

Why it went unnoticed

MacDocDocxIntegrationTests pins itself to .build/debug/macdoc and skips when that binary is absent — so it was skipping, silently, for as long as the checkout had no debug binary. It now runs, and fails. (A sibling defect: CLITestHelper prefers a possibly-stale release binary — PsychQuant/macdoc#187.)

Correcting the earlier suggestion

My original "add the document as a reader fixture so the 3.7.0 fix is guarded" was built on the false premise that there was a fix to guard. The actionable version:

• Reproduce in a test that goes through an async task, not a direct read call, or the test will pass while the CLI crashes.
• If the mechanism is confirmed as recursion depth, an explicit depth bound with a named refusal — the treatment PackageInspector.stripComments 的 <!--.*?--> 對未閉合 <!-- 呈二次退化——5 KB 的 .docx 讓檢查跑一分鐘（follow-up finding from che-word-mcp#199 verify） #138 gave comment stripping — is better than depending on frame size.

Apologies for the noise; the corrected facts are above.