Environment

• MemPalace version: 3.0.0
• Python: 3.14.3 (Homebrew)
• OS: macOS 15.5 (ARM64, Apple M3 Max)
• ChromaDB: bundled with mempalace 3.0.0

Description

After mining ~8,448 drawers across two wings (openclaw_dashboard and dad_health), all MemPalace operations crash with a null pointer dereference in chromadb_rust_bindings.abi3.so. This includes mempalace status, mempalace mine, and any command that touches the palace.

Mining the first two repos succeeded individually, but after both completed (~8,400+ total drawers), every subsequent operation segfaults.

Steps to Reproduce

1. pipx install mempalace==3.0.0
2. mempalace init --yes ~/repos/openclaw-dashboard (mines ~4,200 drawers — succeeds)
3. mempalace init --yes ~/repos/dad-health (mines ~4,200 drawers — succeeds)
4. mempalace status — crashes with segfault

Crash Report

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000

Thread 23 Crashed:
0   chromadb_rust_bindings.abi3.so  0x0000000111eb88e8
1   chromadb_rust_bindings.abi3.so  0x0000000111e87b70
2   chromadb_rust_bindings.abi3.so  0x0000000111e88134
3   chromadb_rust_bindings.abi3.so  0x0000000111e7c470
4   chromadb_rust_bindings.abi3.so  0x0000000111e7c214
5   chromadb_rust_bindings.abi3.so  0x0000000111eb71ac
6   chromadb_rust_bindings.abi3.so  0x0000000111eb711c

The crash is entirely within ChromaDB's Rust bindings — a null pointer dereference at address 0x0. This suggests a size/scaling issue in the ChromaDB vector store when the number of entries exceeds a threshold.

Workaround

Wiping ~/.mempalace/palace and re-mining with smaller batches (testing to find the threshold).

Expected Behavior

mempalace status and subsequent mining should work regardless of palace size, or fail gracefully with an error message instead of segfaulting.