Repository navigation
macOS arm64: mem.allocator.not_owned (0/6 classes) warns on every run of the release binary, but no memory growth is observable #1360
Description
Version
codebase-memory-mcp 0.9.1-rc.1
Platform
macOS (Apple Silicon)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
Every invocation of the darwin-arm64 release binary starts with the allocator-ownership audit failing loudly:
level=warn msg=mem.allocator.not_owned owned_classes=0/6 unowned_bytes=64,4096,65536,262144,1048576,8388608 detail=allocations_in_these_size_classes_are_not_allocator-owned:_purge_and_reclaim_options_do_not_apply_to_them_and_freed_pages_stay_committed
level=info msg=mem.init budget_mb=8601 total_ram_mb=24576 source=ram_fraction
owned_classes=0/6 — that is, none of the six size classes are allocator-owned, on a platform the RC notes describe as cross-checked green ("Verified on release artifacts… cross-checked green on macOS/Linux/Windows", #581). It appears on every CLI call and on daemon startup, so it's also constant noise on stderr for any wrapper that captures it.
I could not find a corresponding leak, so I suspect the audit itself is wrong on macOS rather than the allocator. Measurements on the permanent daemon (daemon start, build 0.9.1-rc.1 e4fe1cf4f764), indexing/querying a 63,840-node / 120,805-edge graph:
| point | daemon RSS |
|---|---|
| after indexing an 11.8k-file repo | 256,528 KB |
after 30 heavy aggregate query_graph calls |
223,360 KB |
after 30 further search_graph calls |
213,968 KB |
| ~1 h later, idle | 6,288 KB |
RSS falls monotonically under load and the daemon returns to ~6 MB when idle — the opposite of a ratchet. So either the ownership check has a false-negative on darwin-arm64, or the wrap/override is genuinely absent there but mimalloc's absence happens not to matter because the system allocator reclaims fine.
Either way the current behaviour is a problem in itself: the audit was added so that "any future regression announces itself at startup", and on macOS it announces unconditionally. That trains users to ignore it, which defeats the purpose.
Expected: either the audit passes on the macOS release artifact, or — if allocator ownership genuinely doesn't apply on darwin — it reports that as an expected platform condition at info/debug level instead of warn.
Reproduction
codebase-memory-mcp cli list_projects < /dev/null 2>&1 >/dev/null | head -2Prints the mem.allocator.not_owned warning on every run. Also present on daemon start and on the MCP server's stderr.
Diagnostics trajectory (memory / performance / leak issues)
RSS table above, sampled with ps -o rss= -p <daemon pid>. Daemon started via codebase-memory-mcp daemon start (permanent). Workload: one index_repository --mode full of an 11,788-file Angular monorepo (63,840 nodes / 120,805 edges, 6.3 s), then 30 × query_graph aggregates over all CALLS edges, then 30 × search_graph, then idle. No memory growth observed at any point; 10 concurrent query_graph calls returned byte-identical correct results with no errors.
Project scale (if relevant)
11,788 files, 63,840 nodes / 120,805 edges, --mode full. 24 GB RAM machine, budget reported as 8,601 MB.
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Posted by Claude Code on behalf of @artaommahe
Activity
artaommahe commentedon Jul 30, 2026
Retracting and closing this — it should not have been filed, and I want to be explicit about why rather than just deleting it.
This is a documented Known Issue of the exact RC I was testing. The v0.9.1-rc.1 release notes, under "Known issues (RC)", say:
I ticked "I searched existing issues and this is not a duplicate" and then filed a pre-declared known issue. Searching the issue tracker is not the same as reading the release notes of the build under test, and I should have done both.
Two factual claims in the body are also wrong, both of which I've since disproved on my own machine:
cli <tool>invocations, which are what initialise the memory subsystem.--version,--help,config listanddaemon statusproduce zero occurrences.cli <tool>stderr and one line per daemon start in~/.cache/codebase-memory-mcp/logs/cbm-daemon.log.My "the RC notes say macOS was cross-checked green, so this contradicts them" argument was also a misreading: that phrase describes the soak growth ratio (53× → 1.06×), not the ownership audit, and ownership is Windows-scoped throughout the notes and throughout #581.
For the record, the memory data in the original report does hold up, and I pushed on it hard trying to find a leak: 50 sequential heavy aggregate queries stayed in a 254–291 MB band with no trend; three consecutive full re-indexes of an 11.8k-file repo left the daemon flat; the daemon returns to single-digit MB when idle. No ratchet on macOS. So the warning is not pointing at a real problem here, which is consistent with your Known Issues entry.
The one residual point, which is a log-hygiene nit and not worth an issue of its own:
mem.allocator.not_ownedis emitted atwarnwith no platform qualifier, on a platform where the build configuration makes0/6the guaranteed outcome (the mimalloc override is gated to MinGW; the POSIX override file is__linux__-only; macOSldhas no--wrap). An unconditionalwarnthat is expected-by-design trains people to ignore the line that is supposed to be the Windows tripwire. If you'd like that as a one-line change request I'm happy to open it as such, or it can just be folded into #581 — your call.CBM_LOG_LEVEL=errorsuppresses it in the meantime.Sorry for the noise.
Posted by Claude Code on behalf of @artaommahe
Merge pull request #1477 from DeusData/fix/linux-allocator-override
fix(mem): route ordinary malloc through mimalloc on Linux (DeusData#1360