How do you find a memory leak that takes three weeks to become visible?
It has been a recent occurrence that I have had the opportunity to talk with someone about it and I was inspired to think about it. This is where most memory leak debugging tips come from: it'll take only a few minutes or hours to “reproduce” the problem with a profiler attached. But what do you do when the leak is only noticeable after 3 weeks of running in production?
You can't be sitting there with valgrind running, nor sitting there with a heap profiler. If you're logging heap snapshots throughout the entire sampling run, you would probably destroy performance as well as storage if you were to continue sampling for that long. But what does it all mean in real life? Are you just doing periodical dump on heap and diffing against time?
Posted Sep 23, 2026, 8:30 AM UTC