1671581 - Firefox fails to run WebAssembly content after a while when one has browser console window open

Status: RESOLVED DUPLICATE of bug 1476869

(Core :: JavaScript: WebAssembly, defect, P3)

Description

[Jukka Jylänki]

Attachment: cube_reload.zip

STR:

1. Download and unzip web page from attached cube_reload.zip
2. Use https://github.com/emscripten-core/emscripten/blob/master/emrun.py or some other web server that understands to apply Content-Type: application/wasm to .wasm files, so that streaming Wasm compilation works
3. Visit the page and open browser console window.
4. Wait for a few hours.

The page will reload itself every 10 seconds. At some point, Firefox will refuse to no longer open the page, but complains about wasm streaming compilation failing.

It looks like the issue does not occur when browser console window is closed. (or if it does, it takes more than ~2 hours to happen)

Comment 1

[Jukka Jylänki]

Attachment: firefox_oom.png

Attached screenshot about the OOM.

The system that this was tested on has 64GB of RAM, so it is odd to see an OOM here.

Comment 2

[Lars T Hansen [:lth]]

I might guess that debug info or esp debug code is accumulated on each reload (because the console is open, although I thought we only did this when the debugger was active) and that we're failing to free it. On 64-bit systems our code budget per process is 1GB and we could easily fill that up. It could also be that we're not scheduling a last-ditch GC to free up memory when we run into some types of OOM.

Comment 3

[Lars T Hansen [:lth]]

After fiddling with this for a while I'm not sure I'm much closer. Content does reach the wasm engine, but sometimes the promise for the streaming compilation is rejected, and there's a "network error" being printed in the console (may or may not be correlated).

The "failed to asynchronously prepare wasm" message is from the emscripten scaffolding, not from the engine itself, in the vein of this code: https://searchfox.org/mozilla-central/source/js/src/jit-test/tests/wasm/bench/wasm_box2d.js#1502. The "out of memory" bit comes from Firefox and would be an exception thrown by the streaming compiler.

Comment 4

[Lars T Hansen [:lth]]

What seems to be the case is that with the console open, the rate of streaming compilation failures is greater than with the console closed. (This is in a debug-noopt build on Linux with a local web server.) With the console closed the failure rate is very low, almost zero. With the console open, failures are frequent. (A failure is when we get to the point in CompileStreamTask::resolve where we call RejectWithStreamErrorNumber.) The failures give rise to the error message as shown in comment 1.

Still not sure what this amounts to. I'll P3 this as it's unlikely to be a huge problem at the moment, but it may fit in with the group of weird OOM problems we already have reports about. I'll leave it running until it OOMs or I get tired of it.

Comment 5

[Lars T Hansen [:lth]]

Probably same issue as bug 1710577.

Comment 6

[Lars T Hansen [:lth]]

The fix to bug 1714086 helps make the problem reported here manageable, but the real problem is bug 1476869.