Detecting memory leaks in managed languages with Cork

Abstract

SUMMARYA memory leak in a managed program occurs when the program inadvertently maintains references to objects that it no longer needs. Memory leaks cause systematic heap growth which degrades performance and results in program crashes after perhaps days or weeks of execution. Prior approaches for detecting memory leaks rely on heap differencing or detailed object statistics which store state proportional to the number of objects in the heap. These overheads preclude their use on the same processor for deployed long-running applications. This paper introduces Cork as a tool that accurately identifies heap growth caused by leaks. It is space efficient (adding less than 1% to the heap) and time efficient (adding 2.3% on average to total execution time). We implement this approach of examining and summarizing the class of live objects during garbage collection in a class points-from graph (CPFG). Each node in the CPFG represents a class and and edges between nodes represent references between objects of the specific classes. Cork annotates nodes and edges with the corresponding volume of live objects. Cork identifies growing data structures across multiple collections and computes a class slice to identify leaks for the user. We experiment with two functions for identifying growth and show that Cork is accurate: it identifies systematic heap growth with no false positives in 4 of 15 benchmarks we tested. Cork's slice report enabled us to quickly identify and eliminate growing data structures in large and unfamiliar programs, something their developers had not previously done.

Systematic testing for resource leaks in Android applications

“…As discussed in Section III-C, the repetitive nature of the generated test cases presents interesting possibilities for custom variations of heap-differencing techniques (e.g., [8], [10]) and transaction-based leak diagnosis [13]. Future work may also consider generalizations of these approaches for analysis of native memory and resources other than memory.…”

“…The diagnosis was performed with the help of the MAT memory analysis tool [6] (which is commonly used by Android developers [3]), followed by code inspection. An interesting question for future work is how to apply this approach to automated heap-differencing techniques (e.g., [8], [10]) and how to generalize it for analysis of native memory and resources other than memory.…”

“…Sleigh [9] encodes allocation/access sites in a single bit per object to enable low-overhead staleness detection. Cork [10] uses heap summarization to identify sustained growth of object instances. Leaks caused by unnecessary references stored in containers have been targeted through container profiling [11].…”

“…Information derived from such graphs is often analyzed manually to understand memory usage and diagnose memory leaks in Android applications [33]. Various automated analyses of heap graphs have also been proposed (e.g., [8], [10]). Such analyses can potentially be extended to reflect the structure of the generated test cases.…”

Simulation of a Railway Control System: Dynamic Analysis of Scoped Memory Consumption

“…Each periodic run of the Monitor thread will create a new Train Status Table which will be de-allocated after the Monitor thread finishes its current period and is waiting for the next period to start. Hence, no memory leak occurs (a memory leak occurs when unclaimed dead objects, no longer reachable by the application, remain in memory for a relatively long time [7]). Table) will be allocated into one scope and the third will be allocated to a different scope (Designs 3, 4 and 5).…”