Modern web applications often resort to application development frameworks such as React, Vue.js, and Angular. While the frameworks facilitate the development of web applications with several useful components, they are inevitably vulnerable to unmanaged memory consumption since the frameworks often produce Single Page Applications (SPAs). Web applications can be alive for hours and days with behavior loops, in such cases, even a single memory leak in a SPA app can cause performance degradation on the client side. However, recent debugging techniques for web applications still focus on memory leak detection, which requires manual tasks and produces imprecise results. We propose LeakPair, a technique to repair memory leaks in single page applications. Given the insight that memory leaks are mostly non-functional bugs and fixing them might not change the behavior of an application, the technique is designed to proactively generate patches to fix memory leaks, without leak detection, which is often heavy and tedious. To generate effective patches, LeakPair follows the idea of pattern-based program repair since the automated repair strategy shows successful results in many recent studies. We evaluate the technique on more than 20 open-source projects without using explicit leak detection. The patches generated by our technique are also submitted to the projects as pull requests. The results show that LeakPair can generate effective patches to reduce memory consumption that are acceptable to developers. In addition, we execute the test suites given by the projects after applying the patches, and it turns out that the patches do not cause any functionality breakage; this might imply that LeakPair can generate non-intrusive patches for memory leaks.

1. LeakPair: Proactive Repairing of
Leaks in Single Page Web Applications
Arooba Shahoor
Kyungpook National University, Korea
Askar Yeltayuly Khamit
UNIST, Korea
Jooyong Yi
UNIST, Korea
Dongsun Kim
Kyungpook National University, Korea
The 38th IEEE/ACM International Conference on Automated Software Engineering (ASE 2023)
14 September 2023
with ACM Distinguished Paper Award

2. 2

4. 4
MOTIVATION

5. Why Are Memory
Leaks Critical in the
SPA Architecture?
5

6. Client
Page switching with reload
User Interface
Page 1
Page 2
Page 3
HTTP Request for
initial page load
HTTP Request for
page transition
Server
<template>
Presentation Layer
Database &
Business Logic
Multi Page Application Architecture
6
New page for each request
Inside the Heap
Object 3
Object 2
Object 4
Object 1
Allocated objects from
previous page all wiped off
On user interactions

7. Client
No reload required
SPA Framework
(Angular/React/Vue..)
Single .html file
<template 1>
<template 2>
<template 3>
View switching without
reload
User Interface
View 1
View 2
View 3
HTTP Request
for initial page
load
AJAX Request for
page transition
Server
Single Page Application Architecture
7
Database &
Business
Logic
Object 3
Object 4
Object 2
Object 1
Object 6
Object 5 This page is never refreshed…
On user interactions
Inside the Heap
Unintentional references
will keep piling up!
Object 7
Object 8
Object 9

8. JavaScript Devs Can’t Rely on Garbage
Collectors

9. Garbage Collection in JS (Mark and Sweep)
Reachability from Root
Object 4
Object 5
Object 2
Object 8
Object 6
Object 7
Object 3
Object 1
View 1 (Inside Heap)
window
(GC ROOT 1)
String
(GC ROOT 2)

10. Garbage Collection in JS (Mark and Sweep)
Reachability from Root
Object 4
Object 5
Object 2
Object 8
UNUSED
Object 7
UNUSED
Object 1
View 2 (Inside Heap)
UNUSED
UNUSED
window
(GC ROOT 1)
String
(GC ROOT 2)

11. Garbage Collection in JS (Mark and Sweep)
Reachability from Root
UNUSED
MARK
Object 5
MARK
Object 2
MARK
UNUSED
MARK
UNUSED
MARK
Object 7
SWEEP
UNUSED
MARK
Object 1
MARK
View 2 (Inside Heap)
Unused objects marked as alive
and will not be GC’ed, due to
reachability from GC root
window
(GC ROOT 1)
String
(GC ROOT 2)

12. Garbage Collection in JS (Mark and Sweep)
Reachability from Root
UNUSED
MARK
Object 5
MARK
Object 2
MARK
UNUSED
MARK
UNUSED
MARK
UNUSED
MARK
Object 1
MARK
View 2 (Inside Heap)
window
(GC ROOT 1)
String
(GC ROOT 2)

13. Garbage Collection in JS (Mark and Sweep)
Reachability from Root
UNUSED
Object 5
Object 2
UNUSED
UNUSED
UNUSED
Object 1
View 3 (Inside Heap)
window
(GC ROOT 1)
String
(GC ROOT 2)
New
object 1
New
object 2
Lingering unwanted objects will
keep gobbling up available space
for newer objects
New
object 3

14. 14
Case in Point
Memory Leak in MS Rooster [2]
Reachable from root
The fix

15. Leak Detection in JS
Automation Efforts (2015-2022)
2015. MemInsight [3] Reports stale objects, by
computing object lifetimes.
2016. LeakSpot [4] Reports all allocation and
reference sites of leaked objects.
2018. Bleak [5] Identifies and reports leaked
objects by running the website in a headless
browser.
2022. Memlab [7] Reports retainer traces of leaked
objects by running the website in a headless
browser.
15

16. MemInsight
LeakSpot
Bleak
Memlab
The Problem With Automated Detection Tools
16
Based on staleness criteria + report leak-related
data rather than actual leak locations
Bleak Takes at least 10 mins to execute
Memlab Reported retainer traces contain metadata and internal
objects, making root cause detection arduous
Require manually-written scenario file

17. State of the Art
● Manual diagnosis via heap snapshots
● Three snapshot technique
● First introduced by Gmail team in 2012
● Detecting root cause can be laborious and inaccurate
17

18. A change of
perspective
18
What we need is…

19. APPROACH
19

20. Proactive
strategy
● Patches that are simple,
non-intrusive and recurring.
● Enable repairs before fault
localization.
● Avoiding detection step is a
huge advantage.
Based on fix patterns [1].
20
[1] D. Kim, J. Nam, J. Song, and S. Kim, “Automatic Patch Generation Learned from
Human-written Patches,” in Proceedings of the 2013 International Conference on Software
Engineering, in ICSE ’13. Piscataway, NJ, USA: IEEE Press, 2013, pp. 802–811.

21. Leak Pattern Mining
● Search targets: GitHub and Stack Overflow.
● Reported at least 5 times.
● Acknowledged by at least 2 developers.
● Replicable and testable.
21

22. Fix Pattern Mining
● Stack Overflow answers accepted in at
least 2 posts.
● GitHub commits merged in at least 2
projects.
● Verified by comparing memory footprints
before and after.
22

23. 4 Leaks and
(Corresponding) Fix
Patterns
23

24. 1. Uncleared Timing Events (setTimeout and setInterval)
{
…
setTimeOut(() => {...})
…
}
{
…
setTimeOut(() => {...})
timeOutID = setTimeOut(() => {...})
...
destructorMethodDeclaration() {
...
clearTimeOut(timeOutID)
}
}
If component unmounts before time, these events will still execute,
retaining references of all enclosing objects.
Fix Pattern
Leak Pattern
Other leak patterns
2. Unreleased subscription
3. Unremoved event listener
4. Uncanceled animation frame request
24

25. Applying Fix Patterns
SPA project Identify JS file(s) Transform to AST Find leak pattern
matches
Match
found?
Apply fix to
AST
Yes
Convert back
to source

26. EVALUATION
26

27. Research Questions
RQ1. Effectiveness How effective is the tool at
minimizing memory leaks?
RQ2. Acceptance How useful are generated patches,
as perceived by developers?
RQ3. Correctness What is the impact of our tool on
test suite execution results?
27

28. Subjects
Known leaks Leaks already detected and fixed by developers.
Unknown leaks Leaks developers were not aware of.
10 open source SPA projects with already known
memory leaks: Microsoft’s Rooster, Fundamental Library for
Angular, Material UI…
10 projects with unfound leaks at the time of
evaluation: Angular Extentions Elements,
react-multi-carousel, ngx-bootstrap…
28

29. 29
Effectiveness Evaluation (RQ 1)
Compare before and after footprints
Execute Memlab
(10 Iterations)
Note memory
footprints
SPA subject
LEAKPAIR
Execute LeakPair
Run the SPA
Subject
Scenario file
(10 Loops)
Note memory
footprints again

30. 30
Effectiveness Evaluation (RQ 1)
Compare before and after footprints
Execute Memlab
(10 Iterations)
Note memory
footprints
SPA subject
LEAKPAIR
Execute LeakPair
Run the SPA
Subject
Scenario file
(10 Loops)
Note memory
footprints again

31. Compare before
and after footprints
31
Acceptance Evaluation (RQ 2)
Is heap size or
leak count
reduced? Yes
Is unknown
leak?
Yes
Submit fix as PR Track PR status

32. 32
Correctness Evaluation (RQ 3)
Execute test suite
(If available)
SPA subject
LEAKPAIR
Execute LeakPair
Run the SPA
Subject
Note build/
compile time
Note passing/failing
test cases
Note build/compile
time and test case
results again
Compare before and after test cases results and execution times

33. RESULTS
33

34. Effectiveness (RQ 1)
● 8 of 10 subjects with known leaks had
noticeable heap reductions.
● 7 of 10 subjects with unknown leaks had
significant heap reductions (4 -18%).
● All subjects had memory leak reductions.
34
LeakPair patches can successfully
prevent leaks and reduce heap,
without leak detection.

35. Acceptance (RQ 2)
● Total = 20 pull requests
● Agreed = 12 (60%)
Merged Approved Improved Ignored
9 2 1 8
35
LeakPair patches are acceptable to
developers, with more than half of
patch suggestions being accepted.

36. Correctness (RQ 3)
● Successful build/compilation
● Count of passing/failing test cases of
10 of 10 unchanged
● Execution times before and after LP
execution shared the same range for
all 10 projects
36
LeakPair patches are non-intrusive;
they neither break functionality, nor
incur execution time delays.

37. Summary
37