BLeak: automatically debugging memory leaks in web applications

Abstract

Despite the presence of garbage collection in managed languages like JavaScript, memory leaks remain a serious problem. In the context of web applications, these leaks are especially pervasive and difficult to debug. Web application memory leaks can take many forms, including failing to dispose of unneeded event listeners, repeatedly injecting iframes and CSS files, and failing to call cleanup routines in third-party libraries. Leaks degrade responsiveness by increasing GC frequency and overhead, and can even lead to browser tab crashes by exhausting available memory. Because previous leak detection approaches designed for conventional C, C++ or Java applications are ineffective in the browser environment, tracking down leaks currently requires intensive manual effort by web developers. This paper introduces BLeak (Browser Leak debugger), the first system for automatically debugging memory leaks in web applications. BLeak's algorithms leverage the observation that in modern web applications, users often repeatedly return to the same (approximate) visual state (e.g., the inbox view in Gmail). Sustained growth between round trips is a strong indicator of a memory leak. To use BLeak, a developer writes a short script (17-73 LOC on our benchmarks) to drive a web application in round trips to the same visual state. BLeak then automatically generates a list of leaks found along with their root causes, ranked by return on investment. Guided by BLeak, we identify and fix over 50 memory leaks in popular libraries and apps including Airbnb, AngularJS, Google Analytics, Google Maps SDK, and jQuery. BLeak's median precision is 100%; fixing the leaks it identifies reduces heap growth by an average of 94%, saving from 0.5 MB to 8 MB per round trip. We believe BLeak's approach to be broadly applicable beyond web applications, including to GUI applications on desktop and mobile platforms.

Prioritising test scripts for the testing of memory bloat in web applications

“…One typical way for memory leak diagnosis is to investigate the memory occupations and growths of data structures, for example, Ref. [6,7,19,20]. Another is to watch the object lifetime information, such as the object staleness, for example, Ref.…”

“…Despite great efforts having already been devoted to the root cause diagnosis of memory bloat in a programme execution with bloat phenomena observed, for example, Ref. [2,[4][5][6][7][8][9], challenges still remain regarding how to first find those memory bloated programme executions.…”

HangFix

“…BLeak [37] automatically debugs the memory leak problem which increases garbage collection frequency and overhead, further degrading responsiveness. Faddegon et al [17] presented a computation tree generaration method that requires only a simple tracing library, for debugging any Haskell programs.…”