Memory leaks are very hard to treat. We have reliable tools like valgrind or AddressSanitizer to tell us whether or not an application has leaked memory, but current tools cannot tell us where the leak happens (they can tell us where the allocation happened,which is not the same).
I show that it is possible to run an analysis that is equivalent to running a garbage detection pass after every instruction and use that to find the actual cause of memory leaks in open source applications.
Using a garbage detection algorithm on record-and-replay recording, one can overcome the most obvious obstacle: stopping a program a program after every instruction or running garbage detection algorithms is very slow, but we can effectively run a bisection search on the recorded timeline to avoid having to evaluate after every instruction.
The goal is attribution to source code. Are we limited to reporting the instruction that overwrites the last reference to allocated memory or can we actually diagnose a specific error for a concrete function?
Tooling Track sessions are sponsored by Optiver.
