memlab 1.1.16 → 1.1.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +99 -7
- package/bin/memlab +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,8 +1,24 @@
|
|
|
1
1
|
# memlab
|
|
2
2
|
|
|
3
3
|
memlab is an E2E testing and analysis framework for finding JavaScript memory
|
|
4
|
-
leaks
|
|
5
|
-
|
|
4
|
+
leaks and optimization opportunities.
|
|
5
|
+
|
|
6
|
+
Online Resources:
|
|
7
|
+
* [Official Website and Demo](https://facebookincubator.github.io/memlab)
|
|
8
|
+
* [Documentation](https://facebookincubator.github.io/memlab/docs/intro)
|
|
9
|
+
|
|
10
|
+
Features:
|
|
11
|
+
* **Browser memory leak detection** - Write test scenario with puppeteer API,
|
|
12
|
+
memlab auto diffs JS heap snapshots, filters out memory leaks, and
|
|
13
|
+
aggregates results.
|
|
14
|
+
* **Object-oriented heap traversing API** - Supports self-defined memory leak
|
|
15
|
+
detector and programmatically analyzing JS heap snapshots taken from
|
|
16
|
+
Chromium-based browsers, Node.js, Electron.js, and Hermes
|
|
17
|
+
* **Memory CLI toolbox** - Built-in toolbox and APIs for finding memory
|
|
18
|
+
optimization opportunities (not necessarily memory leaks)
|
|
19
|
+
* **Memory assertions in Node.js** - Enables unit test or running node.js
|
|
20
|
+
program to take a heap snapshot of its own state, do self memory checking,
|
|
21
|
+
or write advanced memory assertions
|
|
6
22
|
|
|
7
23
|
## CLI Usage
|
|
8
24
|
|
|
@@ -14,7 +30,8 @@ npm install -g memlab
|
|
|
14
30
|
|
|
15
31
|
### Find Memory Leaks
|
|
16
32
|
|
|
17
|
-
To find memory leaks in Google Maps, you can create a
|
|
33
|
+
To find memory leaks in Google Maps, you can create a
|
|
34
|
+
[scenario file](https://facebookincubator.github.io/memlab/docs/api/interfaces/core_src.IScenario) defining how
|
|
18
35
|
to interact with the Google Maps, let's name it `test-google-maps.js`:
|
|
19
36
|
|
|
20
37
|
```javascript
|
|
@@ -45,7 +62,41 @@ the web page and detect memory leaks with built-in leak detectors:
|
|
|
45
62
|
memlab run --scenario test-google-maps.js
|
|
46
63
|
```
|
|
47
64
|
|
|
48
|
-
|
|
65
|
+
memlab will print memory leak results showing one representative
|
|
66
|
+
retainer trace for each cluster of leaked objects.
|
|
67
|
+
|
|
68
|
+
**Retainer traces**: This is the result from
|
|
69
|
+
[an example website](https://facebookincubator.github.io/memlab/docs/guides/guides-find-leaks),
|
|
70
|
+
the retainer trace is an object reference chain from the GC root to a leaked
|
|
71
|
+
object. The trace shows why and how a leaked object is still kept alive in
|
|
72
|
+
memory. Breaking the reference chain means the leaked object will no longer
|
|
73
|
+
be reachable from the GC root, and therefore can be garbage collected.
|
|
74
|
+
By following the leak trace one step at a time, you will be able to find
|
|
75
|
+
a reference that should be set to null (but it wasn't due to a bug).
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
MemLab found 46 leak(s)
|
|
79
|
+
--Similar leaks in this run: 4--
|
|
80
|
+
--Retained size of leaked objects: 8.3MB--
|
|
81
|
+
[Window] (native) @35847 [8.3MB]
|
|
82
|
+
--20 (element)---> [InternalNode] (native) @130981728 [8.3MB]
|
|
83
|
+
--8 (element)---> [InternalNode] (native) @130980288 [8.3MB]
|
|
84
|
+
--1 (element)---> [EventListener] (native) @131009888 [8.3MB]
|
|
85
|
+
--1 (element)---> [V8EventListener] (native) @224808192 [8.3MB]
|
|
86
|
+
--1 (element)---> [eventHandler] (closure) @168079 [8.3MB]
|
|
87
|
+
--context (internal)---> [<function scope>] (object) @181905 [8.3MB]
|
|
88
|
+
--bigArray (variable)---> [Array] (object) @182925 [8.3MB]
|
|
89
|
+
--elements (internal)---> [(object elements)] (array) @182929 [8.3MB]
|
|
90
|
+
...
|
|
91
|
+
```
|
|
92
|
+
To get readable trace, the web site under test needs to serve non-minified code (or at least minified code
|
|
93
|
+
with readable variables, function name, and property names on objects).
|
|
94
|
+
|
|
95
|
+
Alternatively, you can debug the leak by loading the heap snapshot taken by memlab (saved in `$(memlab get-default-work-dir)/data/cur`)
|
|
96
|
+
in Chrome DevTool and search for the leaked object ID (`@182929`).
|
|
97
|
+
|
|
98
|
+
**Self-defined leak detector**: If you want to use a self-defined leak detector, add a `filterLeak` callback
|
|
99
|
+
([doc](https://facebookincubator.github.io/memlab/docs/api/interfaces/core_src.IScenario/#-optional-beforeleakfilter-initleakfiltercallback))
|
|
49
100
|
in the scenario file. `filterLeak` will be called for every unreleased heap
|
|
50
101
|
object (`node`) allocated by the target interaction.
|
|
51
102
|
|
|
@@ -57,7 +108,8 @@ function filterLeak(node, heap) {
|
|
|
57
108
|
```
|
|
58
109
|
|
|
59
110
|
`heap` is the graph representation of the final JavaScript heap snapshot.
|
|
60
|
-
For more details, view the
|
|
111
|
+
For more details, view the
|
|
112
|
+
[doc site](https://facebookincubator.github.io/memlab/docs/api/interfaces/core_src.IHeapSnapshot).
|
|
61
113
|
|
|
62
114
|
### Heap Analysis and Investigation
|
|
63
115
|
|
|
@@ -66,13 +118,14 @@ View which object keeps growing in size during interaction in the previous run:
|
|
|
66
118
|
memlab analyze unbound-object
|
|
67
119
|
```
|
|
68
120
|
|
|
69
|
-
Analyze pre-fetched
|
|
121
|
+
Analyze pre-fetched V8/hermes `.heapsnapshot` files:
|
|
70
122
|
|
|
71
123
|
```bash
|
|
72
124
|
memlab analyze unbound-object --snapshot-dir <DIR_OF_SNAPSHOT_FILES>
|
|
73
125
|
```
|
|
74
126
|
|
|
75
|
-
Use `memlab analyze` to view all built-in memory analyses.
|
|
127
|
+
Use `memlab analyze` to view all built-in memory analyses.
|
|
128
|
+
For extension, view the [doc site](https://facebookincubator.github.io/memlab).
|
|
76
129
|
|
|
77
130
|
View retainer trace of a particular object:
|
|
78
131
|
```bash
|
|
@@ -100,3 +153,42 @@ const scenario = {
|
|
|
100
153
|
}
|
|
101
154
|
memlab.run({scenario});
|
|
102
155
|
```
|
|
156
|
+
|
|
157
|
+
## Memory Assertions
|
|
158
|
+
|
|
159
|
+
memlab makes it possible to enable a unit test or running node.js program
|
|
160
|
+
to take a heap snapshot of its own state, and write advanced memory assertions:
|
|
161
|
+
|
|
162
|
+
```typescript
|
|
163
|
+
// save as example.test.ts
|
|
164
|
+
import type {IHeapSnapshot, Nullable} from '@memlab/core';
|
|
165
|
+
import {config, getNodeInnocentHeap} from '@memlab/core';
|
|
166
|
+
|
|
167
|
+
class TestObject {
|
|
168
|
+
public arr1 = [1, 2, 3];
|
|
169
|
+
public arr2 = ['1', '2', '3'];
|
|
170
|
+
}
|
|
171
|
+
|
|
172
|
+
test('memory test with heap assertion', async () => {
|
|
173
|
+
config.muteConsole = true; // no console output
|
|
174
|
+
|
|
175
|
+
let obj: Nullable<TestObject> = new TestObject();
|
|
176
|
+
// get a heap snapshot of the current program state
|
|
177
|
+
let heap: IHeapSnapshot = await getNodeInnocentHeap();
|
|
178
|
+
|
|
179
|
+
// call some function that may add references to obj
|
|
180
|
+
rabbitHole(obj)
|
|
181
|
+
|
|
182
|
+
expect(heap.hasObjectWithClassName('TestObject')).toBe(true);
|
|
183
|
+
obj = null;
|
|
184
|
+
|
|
185
|
+
heap = await getNodeInnocentHeap();
|
|
186
|
+
// if rabbitHole does not have any side effect that
|
|
187
|
+
// adds new references to obj, then obj can be GCed
|
|
188
|
+
expect(heap.hasObjectWithClassName('TestObject')).toBe(false);
|
|
189
|
+
|
|
190
|
+
}, 30000);
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
For other APIs check out the
|
|
194
|
+
[API documentation](https://facebookincubator.github.io/memlab/docs/api/interfaces/core_src.IHeapSnapshot#hasobjectwithclassnameclassname).
|
package/bin/memlab
CHANGED