1693256 - Firefox on Android crashes/reloads the tab if too much JS ArrayBuffer memory is allocated

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Jukka Jylänki]

Attachment: wasm_memory_test.html

STR: Visit https://clbri.com/wasm_memory_test.html on Firefox on Android.

Click on "Grow JS" until the tab crashes.

Expected: The tab should throw an allocation error instead.

Attached the same wasm_memory_test.html to this bug, it is a self-contained html file.

Comment 1

[Jukka Jylänki]

To be more precise, the behavior on this page is that it allocates geometrically growing alloc sizes (64KB, 128KB, 256KB, ...), until reaching Firefox max 2GB-1 size. After first allocation of 2GB fails, it starts to shrink the allocations again geometrically (2GB, 1GB, ...), until finding an allocation size that succeeds again.

The behavior I am seeing is that all allocations succeed up to the first 2GB allocation. Then the 2GB allocation (successfully) fails, and a log print is outputted on the page about that. Then on the very next allocation, a 1GB alloc is attempted, but instead of failing by throwing an exception like the 2GB allocation did, the 1GB allocation immediately triggers a page reload.

Under this scheme, when memory is constrained, I would not expect tiny allocation sizes (like 64KB) to have any guarantees about stability, but having already a huge 1GB alloc trigger a page reload instead of a graceful OOM is what is peculiar here.

Comment 2

[Lars T Hansen [:lth]]

Given that the program hangs onto all the memory it's allocated, there will be significant memory pressure here. In the worst case it could be some overcommit problem that is encountered while touching the memory. We probably need a crash log to say more, I'll see if I can generate one.

Comment 3

[Lars T Hansen [:lth]]

Feb 14 FF Nightly on Nokia 5.1 Plus, Android 10 / Jan 2021 update, I reliably crash after the 512MB mark on the way up, after which the browser is sometimes unstable (indeed the device UI is unstable until I quit the browser), sometimes the browser seems to recover OK and can rerun the test. No log output that I notice.

I agree large allocs should not cause crashes, so there's an issue here, but it could be that the large alloc succeeds and that running the JS script after to touch the memory has a small-alloc OOM (or crashes because of overcommit).

Alas, about:crashes is empty.