Bug 222097 – Reloading web page with Wasm causes Wasm to have less and less Wasm memory available

• Component: WebAssembly
• Status: RESOLVED CONFIGURATION CHANGED

STR:

1. Visit http://clb.confined.space/wasm_grow.html (you can download this for local examination, the file is standalone/self-contained)
2. Click on "new WebAssembly.Memory({ initial: 1 });" button
3. Click on "Grow Wasm" button repeatedly, until "wasm.buffer.byteLength == " field is no longer able to grow.
4. Observe the amount of memory that was possible to be reached.
5. Click on Reload and go to step 2.

Observed:

On subsequent page reloads, there is less and less memory available for the Wasm heap to grow. E.g. in one such test, max heap went from 768 MB -> 544 MB -> 512 MB on each page reload.

[Alexey Proskuryakov]

Which version of Safari are you seeing this with? Safari 13 as set in Version field is very old, and thus bugs in it are not relevant unless also happening with the latest version.

This was tested on iPhoneXS on iOS 13.3.1. My apologies for not testing a newer version, but iOS refuses to update itself on my phone. It is stuck in a "Update Available -> Install Update -> Verifying Update -> Unable to Install Update, An error occurred when installing iOS 14.4" sequence when attempting to install iOS 14.4, and I do not have another iOS device to test.

Based on reports from this thread https://forum.unity.com/threads/android-chromium-unable-to-grow-allocated-memory-above-256mb-confirmed.1014475/ , and the conversation in this thread, https://github.com/WebAssembly/design/issues/1397 I believe that the issues are still current.

However please close if this is not actionable to investigate further. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/74735924>

[Smoley]

Still reproduces on the latest iOS 14.5 beta.

[Justin Michaud]

I cannot reproduce this on 13.3/M1 Macbook. We always get the full 4.0000 GB.

On iOS 16.4, iPhone Xs, I similarly always get 1.9062gb if we ask for it from the beginning.

On the other hand, if we ask for a fixed smaller amount, we are often unable to grow the memory. Reloading doesn't seem to matter here, this has more to do with our heap layout.

I also get "this page is reloaded because it is using significant memory," even though I have 32gb of ram. We should tune that heuristic.

[goldwaving]

It is frustrating that this issue still has not been resolved.  Reload of our audio editing app triggers this bug.  You can test it here:  https://goldwave.com/editor.

Reloading the page (usually just 2 or 3 times) fails on Safari version 17.2 with a memory range error, but Firefox and Chrome work fine (on non-iOS devices).  The error continues for every reload until Safari is terminated.

[Ivan Čurić]

This issue is even more apparent in iOS 17.3.

Our product (https://demo.microblink.com/blinkid-extract) no longer works on iOS 17.3 as any memory allocation request gets denied after an initial size of 200mb.

Using a fixed memory size without grow calls can also trigger this issue.

If using shared memory, closing the tab won't fix the issue. You need to restart the entire browser.

[Ivan Čurić]

Additionally, here are my test results using http://clb.confined.space/wasm_grow.html on iOS 17.3:

1. Probing will return 815mb - grow fails
2. Clicking "reload" and probing will then return 0.99gb - grow fails
3. Reloading and allocating 1 page, and pressing grow will error out at only 4mb
4. Doing a page reload, allocating 1 page and then growing errors out at 768mb
5. Reloading page + probe returns 1.4678gb
6. Reloading page + initial size of 524mb fails initial allocation.
7. Reloading + initial size of 384 works. Grow fails.
8. Reloading + initial size of 800mb works. Grow works.
9. Reloading + initial size of 181 mb fails.

It's completely unpredictable and therefore unusable in production. Depending on the conditions you can error out at 2gb or at 4mb, asking upfront or growing.

This has been an issue for 3 years now and seems to be getting worse.

[Ahmad Saleem]

@Justin & @Yusuke - does Gigacage commit - https://github.com/WebKit/WebKit/commit/416a9ccb3e0c77d9dccdf2d10689ba7c98b1738b

will help this?

[Alex Suzuki]

I am seeing this issue manifest as well, seemingly more often in recent iOS versions (17.4 and 17.5), when testing a barcode scanning library that uses WASM.
Only killing Safari resolves the issue.

[Alex Suzuki]

Created attachment 471670 [details]
Screenshot of Instruments memory profile of MobileSafari (iOS 17.5.1)

Instruments screenshot of MobileSafari process when issue occurs. On iOS 17.5.1, on an iPhone 15 Pro (MTV63ZD/A) the issue starts happening when memory usage of MobileSafari hits 6.0 GB.

[Alex Suzuki]

Reproduction repository: https://github.com/pixelverse-llc/safari-wasm-oom-reproducer

Repeatedly reloading index.html triggers the issue after an unknown number of refreshes (~a dozen in my experiment)

[Alex Suzuki]

Created attachment 471697 [details]
Reproduction repository; Refresh a dozen or so times and it triggers the OOM condition, and does not recover.

[Alex Suzuki]

Note: I can not reproduce this issue in the Safari iOS 18 Developer Beta (22A5282m).

[Alex Suzuki]

I can also no longer reproduce this in Safari on iOS 17.6 Beta.

[Alexey Proskuryakov]

Thank you for following up!

[Alex Suzuki]

Tested this today on iOS 17.6 (21G80) using the reproduction repo at https://github.com/pixelverse-llc/safari-wasm-oom-reproducer which uses an initial allocation of 64 MB, and apparently it is not fixed. The issue persists over page refreshes, but closing the browser tab now seems to clear the error state. Can someone confirm?

[Alex Suzuki]

@Alexey can we move this back to CONFIRMED or a state that is not RESOLVED? The issue is still present in iOS 17.6.

[Alexey Proskuryakov]

This is believed to have been resolved by https://commits.webkit.org/277115@main, which only went into iOS 18, not 17.6. There are many factors at play here though, so I wouldn't be surprised if the full story was more complicated.

Please file a new bug if similar issues are still reproducible with iOS 18 beta. I don't think that testing iOS 17.6 would give us much at this point, unfortunately.

[Alex Suzuki]

@Alexey thanks for responding and confirming that the fix didn't make it into iOS 17.6.

I will observe how this develops in the iOS 18 Betas and file a new ticket if I can reproduce it there. Bit worried about your comment that it could turn out to be more complicated, but happy to hear that something is being done. You commenting here means a lot.

[Ivan Čurić]

This issue is still present in 18.0.1:

https://www.youtube.com/watch?v=4W_ScbuM0HI

[Mark Lam]

(In reply to Ivan Čurić from comment #21)
> This issue is still present in 18.0.1:
> 
> https://www.youtube.com/watch?v=4W_ScbuM0HI

Ivan, if you believe there is still an issue, please file a new bug and include details of:
1. What the issue is.
2. Steps to reproduce the issue, and what are the telltale signs of the issue manifesting (actual behavior) vs not (expected behavior).

Posting a video in a bug that is already resolved will probably not get any action because (1) this bug is already resolved, and (2) no one else knows what you're intending to show with that video.

For all we know, your issue isn't even the same issue as this one.

[Ivan Čurić]

You're correct, as I was demonstrating a different error

Opened a new issue at https://bugs.webkit.org/show_bug.cgi?id=281657#c1.