You’ve been debugging that memory growth for three days. You’ve checked every reference, every Arc, every Box. Rust’s compiler promised you safety. But your production service is eating RAM like it’s going out of style. You’re about to rewrite everything. Stop.
It’s not your code. It’s the allocator.
I’ve been there. A service I worked on jumped from 1GB to 4GB in a few hours. No leaks. No dangling pointers. Just the allocator refusing to give memory back to the OS. The logs showed freed allocations, but the RSS kept climbing. The team was ready to tear apart the entire async runtime. Then someone whispered: glibc malloc.
Here’s the dirty secret: Rust’s compile-time memory safety is a promise. The allocator is a loophole. The default allocator on Linux (glibc malloc) does not return freed memory to the OS immediately. It hoards it in thread-local caches for performance. Your Rust code frees memory, but the allocator says, ‘Nah, I’ll keep it just in case.’ The result: a memory footprint that grows monotonically, looking exactly like a classic leak.
This isn’t a bug. It’s a deliberate optimization. What looks like a critical bug in your code is actually a feature of your C-level allocator working exactly as designed. And that’s the twist that will drive you crazy: the system that makes Rust safe (no garbage collector, manual control) is the same system that lets this problem hide. You can’t blame the borrow checker. You can’t blame your team. You have to blame a piece of C code written decades ago, optimized for throughput, not for memory pressure.
So what do you do? First, stop hunting ghosts. Check your allocator settings. Use jemalloc or mimalloc instead of glibc malloc. They release memory more aggressively. Or tune the glibc arena thresholds. Or simply accept the trade-off: your service uses more memory, but it’s faster. The choice is yours.
Next time you see a ‘memory leak’ in Rust, check the allocator before blaming your code. You might save yourself three days of agony.
FAQ
Q: How can I tell if the memory growth is from the allocator and not a real leak?
A: Use a memory profiler like Valgrind or heaptrack. If freed allocations are retained in the allocator's caches, you'll see blocks with no corresponding references. Check RSS vs. actual heap usage. Try switching to jemalloc or mimalloc—if the growth stops, the allocator was the culprit.
Q: Is it safe to replace glibc malloc with another allocator in production?
A: Yes, many Rust projects use jemalloc by default (e.g., through the `tikv-jemallocator` crate). It's well-tested and often reduces memory fragmentation. However, benchmark first—some allocators trade memory for speed, or vice versa. The change is straightforward and reversible.
Q: Doesn't this contradict Rust's promise of memory safety?
A: No. Rust's safety guarantees are about preventing undefined behavior (use-after-free, double-free, etc.). The allocator's behavior is a performance optimization, not a safety violation. But it does break the illusion of 'no memory leaks'—Rust doesn't promise zero memory usage growth, only correct memory management.