fix(store): drop the SQLite page-cache slab that faults on arm64 - #1274
Merged
Conversation
The slab was a static char array handed to SQLITE_CONFIG_PAGECACHE. A static char array carries no alignment guarantee and SQLite requires 8-byte-aligned page-cache memory: x86_64 tolerates the unaligned access, arm64 faults. Every suite that opens a store died instantly on windows-11-arm with STATUS_ILLEGAL_INSTRUCTION (pass=0, secs=0) while pure-logic suites in the same wave passed, and both arm64 shards were green on the commit before the merge. It was also never the fix it was added for: measurement showed the slab installed correctly and #581's growth unchanged, because the cause was thread heaps never being released. Removing it rather than aligning it -- an unverified optimisation has no claim on a release gate. Note PR CI does not build the windows-11-arm leg, so this class of defect can only surface in the dry run. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
timothybrush
pushed a commit
to timothybrush/codebase-memory-mcp
that referenced
this pull request
Jul 26, 2026
This reverts commit f843db8, which removed the DeusData#581 fix on a false attribution. The arm64 shards were crashing because of an unaligned SQLite page-cache slab (fixed in DeusData#1274, arm64 shard 2/2 green since); removing this callback never changed those crashes, which is what exonerated it. The Windows soak then failed for the obvious reason: the leak was back. Static MinGW links have no DllMain and register no TLS callback, so mi_thread_done never runs and every thread leaks its heap -- 607 heaps after 300 requests holding 170 MiB against a ~300 KiB live set. With the callback the 10-minute Windows soak measured 1.1x against the original 53x. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The slab was a
static chararray handed toSQLITE_CONFIG_PAGECACHE. A static char array carries no alignment guarantee and SQLite requires 8-byte-aligned page-cache memory: x86_64 tolerates the unaligned access, arm64 faults.Every suite that opens a store died instantly on
windows-11-armwithSTATUS_ILLEGAL_INSTRUCTION(pass=0 secs=0) while pure-logic suites in the same wave passed. Both arm64 shards were green on the commit before the merge that introduced it.It was also never the fix it was added for: measurement showed the slab installed correctly (
config_failed=0) and #581's growth unchanged, because the cause was thread heaps never being released. Removing rather than aligning it — an unverified optimisation has no claim on a release gate.Note
PR CIdoes not build thewindows-11-armleg, so this defect class can only surface in the Dry Run.