chromadb_rust_bindings segfaults on macOS 26.4 (Darwin 25.4) ARM64 — all >=1.5.4,<2 versions affected

chromadb_rust_bindings segfaults on macOS 26.4 (Darwin 25.4) ARM64 — all >=1.5.4,<2 versions affected

Summary

On macOS 26.4.1 / Darwin 25.4 ARM64, every version of chromadb that mempalace 3.3.4 allows (>=1.5.4,<2) crashes with EXC_BAD_ACCESS SIGSEGV inside chromadb_rust_bindings.abi3.so the moment client.get_collection() is called on an existing palace.

The crash is upstream of mempalace — a minimal repro using the chromadb Python package alone reproduces it — but it fully disables the following mempalace commands on this platform:

• mempalace status (exit 139)
• mempalace migrate (exit 139)
• mempalace mine <dir> (real run; dry-run survives because it doesn't open the collection)
• Any direct mempalace.palace.get_collection() call

Counterintuitively, the MCP server (mempalace-mcp) keeps running and serves search/diary/KG requests successfully. mempalace search on the CLI also works. I haven't dug into why those paths survive — possibly because they don't go through the same Rust segment-open path on cold start, or they have retry logic.

Impact

The user-facing symptom is that closets count stays at 0 forever — because every mempalace mine invocation silently segfaults after chromadb is opened, leaving exit code 0 (the parent script sees no output and treats it as "deduped, nothing to do"). Without mine ever succeeding, the v3.3 closets index is never populated, and the user never gets the v3.3.0 +38% retrieval boost.

I lost ~2 days assuming closets=0 was a configuration issue before finding the segfault by running the same code under python3 -c which surfaces the exit 139.

Repro

Minimal — does NOT involve mempalace:

python3 -c "
import chromadb, os
client = chromadb.PersistentClient(path=os.path.expanduser('~/.mempalace/palace'))
col = client.get_collection('mempalace_drawers')
print(col.count())
"
# exit=139, segfault

The palace was originally built by mempalace 3.1.0, then upgraded to 3.3.4 (data intact, 14,778 drawers, 635 KG triples).

Versions tested (all crash identically)

Other variables also tested:

• numpy 2.4.3 → segfault
• numpy 1.26.4 → still segfault (numpy ABI is not the cause)

Crash report

Exception: EXC_BAD_ACCESS SIGSEGV
Subtype:   KERN_INVALID_ADDRESS at 0x0000000000000000

Crashed thread 33:
  0  chromadb_rust_bindings.abi3.so  +0x1788280
  1  chromadb_rust_bindings.abi3.so  +0x1786bf4
  2  chromadb_rust_bindings.abi3.so  +0x1782f54
  3  chromadb_rust_bindings.abi3.so  +0x1780058
  4  chromadb_rust_bindings.abi3.so   +0x7e2060
  5  chromadb_rust_bindings.abi3.so   +0x931e60
  6  chromadb_rust_bindings.abi3.so   +0x861d54
  7  chromadb_rust_bindings.abi3.so   +0x8de67c
  8  chromadb_rust_bindings.abi3.so   +0x857ca0
  9  chromadb_rust_bindings.abi3.so   +0x857f50
 10  chromadb_rust_bindings.abi3.so   +0x8de72c
 11  chromadb_rust_bindings.abi3.so   +0x857ab0
 12  chromadb_rust_bindings.abi3.so   +0x857f50
 13  chromadb_rust_bindings.abi3.so   +0x8de72c
 14  chromadb_rust_bindings.abi3.so   +0x857ab0
 15  chromadb_rust_bindings.abi3.so   +0x857f50
 16  chromadb_rust_bindings.abi3.so   +0x8de72c
 17  chromadb_rust_bindings.abi3.so   +0x857ab0
 18  chromadb_rust_bindings.abi3.so   +0x857f50
 19  chromadb_rust_bindings.abi3.so   +0x8de72c

Frames +0x857ab0 / +0x857f50 / +0x8de72c repeat in a regular 3-frame cycle — looks like a recursive call chain bottoming out in a null deref. Possibly a Rust segment loader walking a corrupted / unexpected on-disk pointer chain.

UUID of the binding: ee0cbdba-0ca1-3a22-b040-c01558769e0d (arch arm64, size 46350336 bytes, installed by chromadb 1.5.8 from PyPI wheel chromadb-1.5.8-cp39-abi3-macosx_11_0_arm64.whl).

Environment

• macOS: 26.4.1 (build 25E253)
• Kernel: Darwin 25.4.0 / RELEASE_ARM64_T8112 (M-series)
• Python: 3.11.2 (python.org installer, framework build)
• Architecture: arm64
• mempalace: 3.3.4
• chromadb: 1.5.8
• chroma-hnswlib: 0.7.6
• Palace size: 125 MB, 14,778 drawers across 16 wings

What I'd love to ask

1. Is this a known incompatibility between chromadb 1.5.x's Rust segment loader and macOS 26.x / Darwin 25.x?
2. Is there a way to opt mempalace 3.3.4 out of the Rust segment path (e.g. via env var, fall back to chromadb's pure-Python loader)?
3. Should I escalate this issue to chroma-core/chroma upstream instead of MemPalace/mempalace? Happy to do so if you confirm.

Workaround in place

For now I'm running mempalace 3.3.4 with the MCP server only:

• MCP-mediated search/diary/KG operations work
• BM25 search via mempalace search works
• Closets stay at 0 (no v3.3 retrieval boost)
• I added a wrapper around mempalace hook run --hook stop to silence info-level stderr (the "HNSW mtime gap NNNs" log line) because Claude Code's hook system reports any stderr as a non-blocking error, polluting transcripts

Happy to test patches / debug builds if useful.