wasm memory leak
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Tracking
()
People
(Reporter: bjornbaron, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
I am using Firefox Developer Edition 80.0b2 (64-bit).
- Un-gzip the attached
rustc_binary.wasm.gz
. - Place the following html file next to it. Let's call it
repro.html
. - Start a webserver using for example
python3 -m http.server -b 127.0.0.1 -d .
. - Go to
http://127.0.0.1:8000/repro.html
. - Refresh the page a couple of times.
<details><summary>The html</summary>
<meta charset="utf-8">
<script type="module">
(async function () {
document.body.innerText = "Downloading";
let wasm = await WebAssembly.compileStreaming(fetch("rustc_binary.wasm"));
document.body.innerText = "Instantiating";
let args = ["rustc"];
let inst = await WebAssembly.instantiate(wasm, {
"wasi_snapshot_preview1": {
proc_exit() { console.log("proc_exit"); },
random_get() { console.log("random_get"); },
args_sizes_get(argc, argv_buf_size) {
console.log("args_sizes_get(", argc, ", ", argv_buf_size, ")");
return -1;
},
args_get(argv, argv_buf) {
console.log("args_get(", argv, ", ", argv_buf, ")");
return -1;
},
clock_time_get() { console.log("clock_time_get"); return 0; },
fd_close() { console.log("fd_close"); },
fd_filestat_get() { console.log("fd_filestat_get"); },
fd_read() { console.log("fd_read"); },
fd_readdir() { console.log("fd_readdir"); },
fd_seek() { console.log("fd_seek"); },
fd_write(fd, iovs_ptr, iovs_len, nwritten_ptr) {
let buffer8 = new Uint8Array(inst.exports.memory.buffer);
let buffer32 = new Uint32Array(inst.exports.memory.buffer);
console.log("fd_write(", fd, ", ", iovs_ptr, ", ", iovs_len, ", ", nwritten_ptr);
buffer32[nwritten_ptr / 4] = 0;
for (let i = 0; i < iovs_len; i++) {
let [ptr, len] = [buffer32[iovs_ptr/4 + 2*i], buffer32[iovs_ptr/4 + 2*i + 1]];
document.body.innerText += new TextDecoder("utf-8").decode(buffer8.slice(ptr, ptr+len));
console.log(ptr, len);
buffer32[nwritten_ptr / 4] += len;
}
return 0; // errno
},
path_create_directory() { console.log("path_create_directory"); },
path_filestat_get() { console.log("path_filestat_get"); },
path_link() { console.log("path_link"); },
path_open() { console.log("path_open"); },
path_readlink() { console.log("path_readlink"); },
path_remove_directory() { console.log("path_remove_directory"); },
path_rename() { console.log("path_rename"); },
path_unlink_file() { console.log("path_unlink_file"); },
sched_yield() { console.log("sched_yield"); },
fd_prestat_get() { console.log("fd_prestat_get"); },
fd_prestat_dir_name() { console.log("fd_prestat_dir_name"); },
environ_sizes_get() { console.log("environ_sizes_get"); },
environ_get() { console.log("environ_get"); }
}
});
document.body.innerText = "Executing\n";
console.log(inst.exports);
inst.exports.main();
document.body.innerText = "Done";
})();
</script>
</details>
Actual results:
Every time I refresh the page the memory usage increases by 200MB. Only closing the tab helps. Even using the GC, CC or minimize memory usage buttons on about:memory don't help.
Expected results:
All memory used by the page should be freed when refreshing.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
rustc_binary.wasm.gz
was just a bit too big to attach. Recompressed as xz
.
Comment 4•4 years ago
|
||
The severity field is not set for this bug.
:lth, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Comment 5•3 years ago
|
||
Firefox 91 Nightly (local release build), Fedora 33, x64. Unable to reproduce at this time, tried both with and without e10s, tried various reload strategies (single reloads between measurements, multiple reloads); measured with about:memory, which did not indicate any leak.
Watching the memory use of the Web Content process in the process viewer and doing several rapid reloads: memory use climbs quickly from about 200MB to over 1GB, but then drops down to 200MB again over about 30s or so, as the GC goes to work.
Comment 6•3 years ago
|
||
I think this is probably bug 1714086, if there's a chance that you had the console window open while you were testing. The timing is not completely right: DevEd 80 should have exhibited a much more massive leak than you report, but there's a possibility that the regressing bug 1628426 wasn't in the build you had, in which case a 200KB leak per reload is exactly right for the test case (with the console window open).
(Bug 1714086 was found because I was playing around with your test case with the console window open, so thank you for that!)
Yeah, I probably had the console window open. Thanks for investigating!
Updated•3 years ago
|
Description
•