Handle cross-thread slab frees#782
Open
SS-42 wants to merge 1 commit into
Open
Conversation
2ae8c34 to
5f891fe
Compare
Signed-off-by: SS-42 <noreply@incogni.to>
5f891fe to
b391b01
Compare
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
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.
Summary
This fixes slab allocator ownership for tree-sitter allocations that are freed on a different parser thread than the one that allocated them.
The allocator now keeps a global slab-page registry. Each page still has an owner thread for reuse, but cross-thread frees are recognized as slab pointers instead of falling through to plain
free(). Reclaim/destroy detaches pages with no live chunks and retires pages that still have live chunks, freeing them when the final chunk is returned.The slab payload is explicitly aligned to
max_align_t; ASan/UBSan caught misaligned slab chunks after the page metadata changed.Observed environment: macOS 26.5.2 (25F84), Darwin 25.5.0 arm64, Apple clang 21.0.0. The crash signature was observed through macOS malloc diagnostics, but the allocator ownership bug is not macOS-specific.
Test plan
make -f Makefile.cbm build/c/test-runner CC=clang CXX=clang++ASAN_OPTIONS=detect_leaks=0 ./build/c/test-runner memruntime error,SUMMARY: UndefinedBehaviorSanitizer, andERROR: AddressSanitizerASAN_OPTIONS=detect_leaks=0 ./build/c/test-runner pipelineruntime error,SUMMARY: UndefinedBehaviorSanitizer, andERROR: AddressSanitizermake -f Makefile.cbm build/c/codebase-memory-mcp CC=clang CXX=clang++./build/c/codebase-memory-mcp --version