SIGBUS/pagein crash recurs on v0.10.2 despite #314 fixes, under shared-daemon multi-session model

[romanbsd]

Summary

Recurrence of #314 (SIGBUS on macOS arm64 when 2+ sessions share the same cache dir) observed on a version that postdates both landed fixes (#315 CBM_SQLITE_MMAP_SIZE knob, #316 PASSIVE checkpoint).

Crash signature (identical to #314)

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x000000000000000a
Termination:     Namespace SIGNAL, Code 10, Bus error: 10
Signal subtype:  FS pagein error: 22 Invalid argument
ktriageinfo:
  CL  - cluster_pagein past EOF
  APFS - cluster_pagein() failed
  VM  - Filesystem pagein returned an error in vnode_pagein
  VM  - Page has error bit set

Faulting thread stack:

getCellInfo
sqlite3VdbeExec
sqlite3_step
sqlite3_exec
cbm_store_exec
run_post_extraction
cbm_pipeline_run
handle_index_repository
main

Environment

• codebase-memory-mcp: crashes span builds installed 2026-08-10 → 2026-08-11 12:25 (auto-updated across v0.10.0 → v0.10.1 → v0.10.2 during that window per release timestamps; currently pinned at v0.10.2, build 516e587c13e8)
• macOS 26.6.1 (25G76), Apple Silicon (arm64)
• Architecture in use: single shared daemon (--cbm-daemon-internal) + up to 10 concurrent thin client processes (multiple Claude Code / Cursor sessions/windows) attached to the same project cache dir, consistent with the daemon coordination work from feat: coordinate concurrent CBM sessions #1139

What happened

42 separate .ips crash reports for codebase-memory-mcp accumulated between 2026-08-10 11:22 and 2026-08-11 12:25, all with the identical SIGBUS/pagein-22/cluster_pagein past EOF signature, all faulting inside handle_index_repository → run_post_extraction → sqlite3_exec. Daemon log (~/.cache/codebase-memory-mcp/logs/cbm-daemon.log) shows indexing is supervised as a subprocess (index.supervisor.reap) that is repeatedly re-spawned by watcher.changed events firing on every file change with 10 clients attached to the same project — i.e. exactly the multi-session-sharing scenario #314 describes.

From a client's perspective this surfaces as Transport closed on any in-flight tool call (e.g. query_graph) made while the supervised worker was mid-crash.

No new crash reports since 2026-08-11 12:25 (before the v0.10.2 auto-update at 17:08 that day) — so it's possible v0.10.2 already narrowed the window, but given the fixes from #314 predate v0.9.0 and this still reproduced on a build that includes them, filing separately rather than assuming it's closed.

Mitigation applied

Set CBM_SQLITE_MMAP_SIZE=0 per the workaround noted in the #314 thread. Have not yet been able to fully verify recurrence is prevented, since the existing daemon (already running before the env var was set) won't restart while other sessions are still attached to it (daemon: NOT stopped — 7 committed client(s) still use it) — will confirm once it cycles naturally.

Ask

• Confirm whether feat(store): expose mmap_size via CBM_SQLITE_MMAP_SIZE env #315/fix(store): use PASSIVE checkpoint to avoid file-shrink under concurrent readers #316 are expected to fully close this under the daemon-coordinated multi-client model from feat: coordinate concurrent CBM sessions #1139, or whether the shared daemon reintroduces a similar truncation race at a different layer (e.g. daemon-triggered reindex racing a client's read, rather than two independent full processes).
• If it's a known gap, linking here for visibility; happy to attach a full raw .ips file if useful.

[DeusData]

Thank you @romanbsd for the stack, crash count, version boundary, and daemon-session context. The current code does not establish that #315/#316 fully close this case: it still defaults SQLite mmap to 64 MiB for both read-only and read/write stores. Shared/live checkpoints are PASSIVE, while the exclusively owned staging store still uses TRUNCATE when sealing before atomic publication.

The run_post_extraction stack is enough to treat this as a real recurrence, but it does not by itself identify which file was shortened or which publication boundary raced the page-in. This is routed priority/high under the indexing-crash epic #390. No further reporter action is required to keep it active; a sanitized full .ips would be useful evidence but is not a blocker.

[DeusData]

@romanbsd — this is one of the best bug reports we have received. 42 crashes with an identical signature, the exact stack, the daemon-log correlation, and a hypothesis that turns out to point at the right place.

Answering your direct question first: no, #315/#316 should not be assumed to close this under the daemon model, and I do not think they do. Those addressed two independent full processes racing on one cache dir. What you are running is different in a way that matters, and your instinct about "a similar truncation race at a different layer" matches what I found reading the code.

What I can confirm from the source:

• Our checkpoints on shared/live paths are deliberately PASSIVE precisely because a TRUNCATE checkpoint can raise SIGBUS in a sibling that has the DB mmap'd on macOS — that hazard is known and guarded (store.c, cbm_store_checkpoint).
• Publication is rename(), which is atomic and does not truncate the old inode, so a reader holding an open fd is safe from that alone.
• But index_supervisor.c states outright that "the spawned workers themselves are fully concurrent." With 10 clients and watcher.changed firing on every file change, you are running the one configuration where multiple index workers can overlap on a single project — and your daemon log showing repeated index.supervisor.reap is consistent with exactly that.

The mechanism I most suspect: -wal and -shm are path-based, while an open connection holds an inode. If worker A publishes by renaming a fresh DB over the live path while worker B is still working against the old inode, B's connection continues using the -wal/-shm at that path — which now belong to a different database. SQLite mmaps the -shm unconditionally, and mmaps main-DB pages when mmap_size > 0 (your getCellInfo frame is a main-DB page read). That is a plausible route to a page fault past EOF that is not covered by the PASSIVE-checkpoint guard.

I want to stress that this is a hypothesis from reading code, not something I have reproduced. I cannot: it needs ~10 concurrent clients driving continuous re-index on one project, on macOS 26.6.1/arm64, and my attempts to force overlapping workers locally have not produced the window. So I would rather ask you for the four things that would settle it than ship a guess.

What would help most, roughly in order:

1. One full .ips file (you offered — yes please). The part I need is the faulting address together with the binaryImages/VM-region section. That tells us which file was mmap'd at that address and how far past its end we faulted — main DB, -wal, or -shm. That single fact eliminates most of the hypothesis space, and it is the one thing I cannot get any other way.

2. The daemon log window around one crash, say ±60s:

   grep -nE "index\.supervisor\.(spawn|reap)|watcher\.changed|store\.(publish|seal|wal)" \
     ~/.cache/codebase-memory-mcp/logs/cbm-daemon.log | tail -80

   What I am looking for is whether two spawn lines appear with no reap between them — that is overlapping workers, and it either confirms or kills the theory outright.

3. A directory listing of the project cache dir, ideally right after a crash:

   ls -la ~/.cache/codebase-memory-mcp/<project>/

   Specifically the sizes and mtimes of *.db, *.db-wal, *.db-shm, and whether any .tmp/staging files are lying around.

4. Confirmation on your CBM_SQLITE_MMAP_SIZE=0 mitigation once the daemon cycles. If crashes stop entirely with mmap off, that confirms the fault is on an mmap'd region rather than ordinary I/O — useful even though it is a workaround, not a fix.

On the mitigation itself: CBM_SQLITE_MMAP_SIZE=0 is the right lever for now and costs you some read throughput, nothing else. Your observation that the daemon will not restart while 7 clients hold it is correct behaviour, though it makes applying the workaround awkward — codebase-memory-mcp daemon stop after closing the editor windows is currently the reliable path, which is not a great answer and is worth its own issue.

Also worth noting: you saw no crashes after 2026-08-11 12:25, before the v0.10.2 update. I would not read that as fixed. Nothing in v0.10.2 or v0.10.3 targeted this, so the more likely explanation is that your workload changed. Please do keep this open.

Marked priority/high and it leads our current fix batch.

[romanbsd]

Here's what I've got for the four items, pulled from the machine that filed this.

1. Full .ips — faulting address + VM region

This is the same crash referenced in the report (2026-08-11-122505.ips, incident C9D8ABAB-96A8-4EF0-8DFA-19616322BC3A). Full JSON below.

Key bit: the faulting address 0x117a34072 sits 5,505,138 bytes (~5.25 MiB) into a 30.9 MiB mapped file region (0x1174f4000–0x1193d4000, Object_id=f9b2c08f, r--/rwx SM=ALI). That region does not appear in usedImages — it's not the executable or a dylib, it's a plain data mmap, which is consistent with it being the main DB (default mmap_size is 64 MiB, matches the getCellInfo/sqlite3VdbeExec frames). The report doesn't resolve the mmap to a filesystem path (Object_id isn't a symbolicated image), so I can't independently confirm main-DB vs. something else beyond that circumstantial match — that would need vmmap at crash time, which is gone now.

Full codebase-memory-mcp-2026-08-11-122505.ips

{"app_name":"codebase-memory-mcp","timestamp":"2026-08-11 12:25:05.00 +0300","app_version":"","slice_uuid":"cea4cdbe-09de-37fe-a3bb-22328d9fe41b","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 26.6.1 (25G76)","roots_installed":0,"incident_id":"C9D8ABAB-96A8-4EF0-8DFA-19616322BC3A","name":"codebase-memory-mcp"}
{
  "uptime" : 85000,
  "procRole" : "Unspecified",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "Mac17,9",
  "coalitionID" : 1811,
  "osVersion" : { "train" : "macOS 26.6.1", "build" : "25G76", "releaseType" : "User" },
  "captureTime" : "2026-08-11 12:25:05.4329 +0300",
  "incident" : "C9D8ABAB-96A8-4EF0-8DFA-19616322BC3A",
  "pid" : 37294,
  "cpuType" : "ARM-64",
  "procLaunch" : "2026-08-11 12:24:59.7945 +0300",
  "procName" : "codebase-memory-mcp",
  "procPath" : "/Users/USER/*/codebase-memory-mcp",
  "parentProc" : "codebase-memory-mcp",
  "parentPid" : 92479,
  "coalitionName" : "com.apple.Terminal",
  "vmRegionInfo" : "0x117a34072 is in 0x1174f4000-0x1193d4000;  bytes after start: 5505138  bytes before end: 26869645\n      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL\n      MALLOC metadata             117474000-1174f4000    [  512K] rw-/rwx SM=PRV  \n--->  mapped file                 1174f4000-1193d4000    [ 30.9M] r--/rwx SM=ALI  Object_id=f9b2c08f\n      GAP OF 0x2d230000 BYTES\n      MALLOC metadata             146604000-14660c000    [   32K] rw-/rwx SM=PRV  ",
  "exception" : {"codes":"0x000000000000000a, 0x0000000117a34072","rawCodes":[10,4691542130],"type":"EXC_BAD_ACCESS","signal":"SIGBUS","subtype":" FS pagein error: 22 Invalid argument"},
  "termination" : {"flags":0,"code":10,"namespace":"SIGNAL","indicator":"Bus error: 10","byProc":"exc handler","byPid":37294},
  "ktriageinfo" : "CL - (arg = 0x0) cluster_pagein past EOF\nAPFS - (arg = 0x3be2001600200040) cluster_pagein() failed\nVM - (arg = 0x1900000016) Filesystem pagein returned an error in vnode_pagein\nVM - (arg = 0x0) Page has error bit set\n",
  "faultingThread" : 0,
  "threads" : [
    {
      "triggered" : true,
      "id" : 5858966,
      "queue" : "com.apple.main-thread",
      "frames" : [
        {"imageOffset":1437300,"symbol":"getCellInfo","symbolLocation":56,"imageIndex":0},
        {"imageOffset":1515560,"symbol":"sqlite3VdbeExec","symbolLocation":40460,"imageIndex":0},
        {"imageOffset":1266772,"symbol":"sqlite3_step","symbolLocation":448,"imageIndex":0},
        {"imageOffset":1271624,"symbol":"sqlite3_exec","symbolLocation":392,"imageIndex":0},
        {"imageOffset":46576,"symbol":"cbm_store_exec","symbolLocation":52,"imageIndex":0},
        {"imageOffset":345560,"symbol":"run_post_extraction","symbolLocation":2732,"imageIndex":0},
        {"imageOffset":340172,"symbol":"cbm_pipeline_run","symbolLocation":4744,"imageIndex":0},
        {"imageOffset":229556,"symbol":"handle_index_repository","symbolLocation":1308,"imageIndex":0},
        {"imageOffset":9988,"symbol":"main","symbolLocation":3552,"imageIndex":0},
        {"imageOffset":132324,"symbol":"start","symbolLocation":6992,"imageIndex":1}
      ]
    },
    {
      "id" : 5858967,
      "frames" : [
        {"imageOffset":17160,"symbol":"__semwait_signal","symbolLocation":8,"imageIndex":4},
        {"imageOffset":56512,"symbol":"nanosleep","symbolLocation":220,"imageIndex":5},
        {"imageOffset":56280,"symbol":"usleep","symbolLocation":68,"imageIndex":5},
        {"imageOffset":11272,"symbol":"parent_watchdog_thread","symbolLocation":44,"imageIndex":0},
        {"imageOffset":27736,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":3},
        {"imageOffset":7196,"symbol":"thread_start","symbolLocation":8,"imageIndex":3}
      ]
    }
  ],
  "usedImages" : [
    {"source":"P","arch":"arm64","base":4329570304,"size":237895680,"uuid":"cea4cdbe-09de-37fe-a3bb-22328d9fe41b","path":"/Users/USER/*/codebase-memory-mcp","name":"codebase-memory-mcp"},
    {"source":"P","arch":"arm64e","base":6635634688,"size":734464,"uuid":"df42dd9d-ad11-33a7-8849-9ad5df30a274","path":"/usr/lib/dyld","name":"dyld"},
    {"size":0,"source":"A","base":0,"uuid":"00000000-0000-0000-0000-000000000000"},
    {"source":"P","arch":"arm64e","base":6639718400,"size":52028,"uuid":"12342372-0084-37a5-9ea6-2e4dc940c685","path":"/usr/lib/system/libsystem_pthread.dylib","name":"libsystem_pthread.dylib"},
    {"source":"P","arch":"arm64e","base":6639464448,"size":250600,"uuid":"7cfb3a10-adb2-32c4-99b5-922a111b3224","path":"/usr/lib/system/libsystem_kernel.dylib","name":"libsystem_kernel.dylib"},
    {"source":"P","arch":"arm64e","base":6638227456,"size":528872,"uuid":"fdc4e366-5c14-3a1e-bc35-d933d28cdcf3","path":"/usr/lib/system/libsystem_c.dylib","name":"libsystem_c.dylib"}
  ],
  "sharedCache" : {"base":6634504192,"size":6010716160,"uuid":"6981b4b9-e090-34ce-862a-41516efef2ad"},
  "vmSummary" : "ReadOnly portion of Libraries: Total=806.6M resident=0K(0%) swapped_out_or_unallocated=806.6M(100%)\nWritable regions: Total=722.1M written=753K(0%) resident=753K(0%) swapped_out=0K(0%) unallocated=721.4M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nIOAccelerator                      1.0G       57 \nKernel Alloc Once                   32K        1 \nMALLOC                           632.5M      149 \nMALLOC guard page                 3664K        4 \nMemory Tag 22                     64.0M        1 \nSTACK GUARD                       56.0M        2 \nStack                             8272K        2 \n__AUTH                              35K       12 \n__AUTH_CONST                       226K       46 \n__DATA                             942K       35 \n__DATA_CONST                      30.8M       44 \n__DATA_DIRTY                       153K       35 \n__LINKEDIT                       573.7M        2 \n__OBJC_RO                         79.2M        1 \n__OBJC_RW                         2599K        1 \n__TEXT                           232.9M       47 \n__TPRO_CONST                       128K        2 \nmapped file                       30.9M        2 \npage table in kernel               753K        1 \nshared memory                       48K        2 \n===========                     =======  ======= \nTOTAL                              2.7G      446 \n",
  "legacyInfo" : { "threadTriggered" : { "queue" : "com.apple.main-thread" } }
}

2. Daemon log window (±60s around the crash)

Can't produce this one, and the reason itself may be useful: the current cbm-daemon.log has no timestamp field on any line (level=info msg=... project=... strategy=... — no ts=), and it doesn't persist/rotate back to 2026-08-11 — it's effectively just the current session's log, currently 166 KB starting from today. So there's no way for me to align "±60s around this specific incident" against it after the fact.

More notable: grepping the entire current log for spawn returns zero matches. Every indexing cycle I can see is logged as a watcher.changed immediately followed by index.supervisor.reap outcome=clean exit_code=0 signal=0 — there's no distinct "spawn" event logged at all in this build. So even going forward, I don't think this log format can answer "did two spawns happen with no reap between them" — that event just isn't emitted. If overlap-detection depends on a spawn log line existing, it may need to be added before this question is answerable from logs at all.

3. Cache dir listing

For the project that's been triggering watcher.changed most (Users-roman-projects-dog), current state:

-rw-------  Users-roman-projects-dog.db      12.2M
-rw-r--r--  dog.db-wal                       0B
-rw-r--r--  dog.db-shm                       32.0K

No .tmp or staging files anywhere in the cache dir right now. WAL is empty (fully checkpointed), which is expected at rest between indexing runs — not much signal either way since this is captured well after the last crash, not immediately after one.

4. CBM_SQLITE_MMAP_SIZE=0 mitigation status

Can't confirm yet, and here's the concrete blocker: the var was added to ~/.zshrc on 2026-08-12 17:00, but the live daemon (pid 2290) has been running since 2026-08-12 14:18 — i.e. it started before the env var was exported, and per daemon status it's still holding 11 committed clients, so it hasn't restarted since. It has never actually run with mmap_size=0.

Separately: no crash reports have landed since 2026-08-11 12:25 — but that's a full day before the mitigation was even applied, so the current crash-free streak isn't evidence for or against the mmap hypothesis. I'll report back once the daemon actually cycles under the new env var and there's been enough indexing activity on shared projects to say something either way.

---

One more data point that lines up with your -shm/inode hypothesis: usedImages in the .ips only lists the executable + 3 dylibs — the 30.9 MiB mapped-file region that faulted isn't a loaded binary image at all, it's a raw data mmap with no resolved path. That's consistent with it being the SQLite main-DB mmap rather than anything code-related, which fits frame 0 (getCellInfo) being a B-tree page read.

[DeusData]

@romanbsd, thank you for supplying the sanitized .ips and for being precise about what the daemon log cannot establish. This completes the reporter-side evidence we asked for.

The getCellInfo -> sqlite3VdbeExec -> run_post_extraction stack and the unmapped-file region are consistent with a main-DB SQLite mmap page-in, while the report correctly does not claim which path or publication overlap caused it. The log gap is also confirmed as operationally material: without timestamps and a spawn event, it cannot prove or disprove overlapping workers after the fact.

No further reporter action is required. Please only add a mitigation result after the daemon has actually restarted with CBM_SQLITE_MMAP_SIZE=0; the current crash-free interval predates that setting and is not evidence either way. This remains priority/high, with the next step on us: instrument and reproduce the worker/publication overlap deterministically. Thank you again for the unusually strong crash evidence.