## Changes ### 1. core/page_arena.c - Removed init failure message (lines 25-27) - error is handled by returning early - All other fprintf statements already wrapped in existing #if !HAKMEM_BUILD_RELEASE blocks ### 2. core/hakmem.c - Wrapped SIGSEGV handler init message (line 72) - CRITICAL: Kept SIGSEGV/SIGBUS/SIGABRT error messages (lines 62-64) - production needs crash logs ### 3. core/hakmem_shared_pool.c - Wrapped all debug fprintf statements in #if !HAKMEM_BUILD_RELEASE: - Node pool exhaustion warning (line 252) - SP_META_CAPACITY_ERROR warning (line 421) - SP_FIX_GEOMETRY debug logging (line 745) - SP_ACQUIRE_STAGE0.5_EMPTY debug logging (line 865) - SP_ACQUIRE_STAGE0_L0 debug logging (line 803) - SP_ACQUIRE_STAGE1_LOCKFREE debug logging (line 922) - SP_ACQUIRE_STAGE2_LOCKFREE debug logging (line 996) - SP_ACQUIRE_STAGE3 debug logging (line 1116) - SP_SLOT_RELEASE debug logging (line 1245) - SP_SLOT_FREELIST_LOCKFREE debug logging (line 1305) - SP_SLOT_COMPLETELY_EMPTY debug logging (line 1316) - Fixed lock_stats_init() for release builds (lines 60-65) - ensure g_lock_stats_enabled is initialized ## Performance Validation Before: 51M ops/s (with debug fprintf overhead) After: 49.1M ops/s (consistent performance, fprintf removed from hot paths) ## Build & Test ```bash ./build.sh larson_hakmem ./out/release/larson_hakmem 1 5 1 1000 100 10000 42 # Result: 49.1M ops/s ``` Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2.1 KiB
2.1 KiB
Critical Bug Report: P0 Batch Refill Active Counter Double-Decrement
Date: 2025-11-07 Severity: Critical (4T immediate crash)
Summary
free(): invalid pointercrash at startup on 4T Larson when P0 batch refill is active.- Root cause: Missing active counter increment when moving blocks from SuperSlab freelist to TLS SLL during P0 batch refill, causing a subsequent double-decrement on free leading to counter underflow → perceived OOM → crash.
Reproduction
./larson_hakmem 10 8 128 1024 1 12345 4
# → Exit 134 with free(): invalid pointer
Root Cause Analysis
- Free path decrements active → correct
- Remote drain places nodes into SuperSlab freelist → no active change (by design)
- P0 batch refill moved nodes from freelist → TLS SLL, but failed to increment SuperSlab active
- Next free decremented active again → double-decrement → underflow → OOM conditions in refill → crash
Fix
- File:
core/hakmem_tiny_refill_p0.inc.h - Change: In freelist transfer branch, increment active with the exact number taken.
Patch (excerpt)
@@ static inline int sll_refill_batch_from_ss(int class_idx, int max_take)
uint32_t from_freelist = trc_pop_from_freelist(meta, want, &chain);
if (from_freelist > 0) {
trc_splice_to_sll(class_idx, &chain, &g_tls_sll_head[class_idx], &g_tls_sll_count[class_idx]);
// FIX: Blocks from freelist were decremented when freed, must increment when allocated
ss_active_add(tls->ss, from_freelist);
g_rf_freelist_items[class_idx] += from_freelist;
total_taken += from_freelist;
want -= from_freelist;
if (want == 0) break;
}
Verification
- Default 4T: stable at ~0.84M ops/s (twice repeated, identical score).
- Additional guard: Ensure linear carve path also calls
ss_active_add(tls->ss, batch).
Open Items
- With
HAKMEM_TINY_REFILL_COUNT_HOT=64, a crash reappears under class 4 pressure.- Hypothesis: excessive hot-class refill → memory pressure on mid-class → OOM path.
- Next: Investigate interaction with
HAKMEM_TINY_FAST_CAPand run Valgrind leak checks.