Critical discovery: TLS SLL head itself is getting corrupted with invalid pointers,
not a next-pointer offset issue. Added defensive sanitization and detailed logging.
Changes:
1. tls_sll_sanitize_head() - New defensive function
- Validates TLS head against SuperSlab metadata
- Checks header magic byte consistency
- Resets corrupted list immediately on detection
- Called at push_enter and pop_enter (defensive walls)
2. Enhanced HDR_RESET diagnostics
- Dump both next pointers (offset 0 and tiny_next_off())
- Show first 8 bytes of block (raw dump)
- Include next_off value and pointer values
- Better correlation with SuperSlab metadata
Key Findings from Diagnostic Run (/tmp/sh8_short.log):
- TLS head becomes unregistered garbage value at pop_enter
- Example: head=0x749fe96c0990 meta_cls=255 idx=-1 ss=(nil)
- Sanitize detects and resets the list
- SuperSlab registration is SUCCESSFUL (map_count=4)
- But head gets corrupted AFTER registration
Root Cause Analysis:
✅ NOT a next-pointer offset issue (would be consistent)
❌ TLS head is being OVERWRITTEN by external code
- Candidates: TLS variable collision, memset overflow, stray write
Corruption Pattern:
1. Superslab initialized successfully (verified by map_count)
2. TLS head is initially correct
3. Between registration and pop_enter: head gets corrupted
4. Corruption value is garbage (unregistered pointer)
5. Lower bytes damaged (0xe1/0x31 patterns)
Next Steps:
- Check TLS layout and variable boundaries (stack overflow?)
- Audit all writes to g_tls_sll array
- Look for memset/memcpy operating on wrong range
- Consider thread-local storage fragmentation
Technical Impact:
- Sanitize prevents list propagation (defensive)
- But underlying corruption source remains
- May be in TLS initialization, variable layout, or external overwrite
Performance: Negligible (sanitize is once per pop_enter)
🤖 Generated with Claude Code (https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
4d2784c52f