[Webkit-unassigned] [Bug 221530] New: Safari browser fails to set boundaries to Wasm application memory

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=221530

            Bug ID: 221530
           Summary: Safari browser fails to set boundaries to Wasm
                    application memory
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebAssembly
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jujjyl at gmail.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210207/0a14890c/attachment.htm>