50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
# Critical Bug Report: P0 Batch Refill Active Counter Double-Decrement
|
|
|
|
Date: 2025-11-07
|
|
Severity: Critical (4T immediate crash)
|
|
|
|
Summary
|
|
- `free(): invalid pointer` crash 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)
|
|
```diff
|
|
@@ 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_CAP` and run Valgrind leak checks.
|
|
|