Bug 221530 - Safari browser fails to set boundaries to Wasm application memory
Summary: Safari browser fails to set boundaries to Wasm application memory
Status: RESOLVED DUPLICATE of bug 269937
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebAssembly (show other bugs)
Version: Safari 14
Hardware: iPhone / iPad iOS 14
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 269777
Blocks:
  Show dependency treegraph
 
Reported: 2021-02-07 10:37 PST by jujjyl
Modified: 2024-02-22 12:37 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jujjyl 2021-02-07 10:37:13 PST
STR:

1. Visit the web site http://clb.confined.space/dump/mem_growth.html
2. Repeatedly click on Allocate Memory until all memory is exhausted.

The page offers a button to repeatedly allocate more memory for a WebAssembly application, until exhausting all possible available memory.
New pages are allocated with wasm memory.grow() operation.

Native compiled applications can be equipped on their own to handle memory allocation failures. I.e. when wasm memory.grow() fails, the calling malloc() for the compiled app will return 0, and the compiled code can manage it as it wishes.

In Safari however, memory.grow() does not fail, but instead Safari kills/(crashes?)/reopens the whole tab without notice. This makes it impossible for application developers to manage memory usage: you can allocate memory up until some unknown amount, which will kill your whole application.

Instead, Safari should limit the amount that wasm memory.grow() can grow, and too large grows should just cap to the limit. This way applications can work against the limit, without risking the page to randomly crash.

Firefox currently has a limit of 2GB in mobile and desktop (which it can easily attain).
Chrome currently has a limit of 4GB on desktop, and due to their mobile browser being 32-bit and hitting address space fragmentation, a limitation of ~500-700MB in practice on mobile.
Comment 1 Keith Miller 2021-02-09 19:06:20 PST
Yeah, I think we could give a better story here. There'


> Native compiled applications can be equipped on their own to handle memory
> allocation failures. I.e. when wasm memory.grow() fails, the calling
> malloc() for the compiled app will return 0, and the compiled code can
> manage it as it wishes.
Comment 2 Keith Miller 2021-02-09 19:12:04 PST
Whoops accidentally submitted while typing my response. Anyway...

I don't think a hard limit is really what we want or what a modern API for memory management would do. Rather, it would be better, IMO, if there was a memory warning event that fires as you approach high memory. But even that won't solve all the problems. For example, on iOS the OS is free to kill any process it wants for using too much memory (too much memory is decided based on system pressure not a fixed limit). Even on Mac it's hard to predict if a tab will go over it's memory budget since that
Comment 3 Keith Miller 2021-02-09 19:13:52 PST
ugh, I did it again... since that is based on the total web content process memory usage.
Comment 4 Radar WebKit Bug Importer 2021-02-09 19:14:34 PST
<rdar://problem/74171413>
Comment 5 Justin Michaud 2024-02-22 12:37:32 PST

*** This bug has been marked as a duplicate of bug 269937 ***