[Webkit-unassigned] [Bug 201028] [WebAssembly] iOS 13 Beta RangeError: Maximum call stack size exceeded.

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Kenneth Pouncey <kepounce at microsoft.com> ---
I will agree that `All browsers have stack depth limits.` It is not only that it has become smaller but applications that worked before in IOS12, no longer work.  

The troubling part is that each mobile device has a separate variable time where it will work.  

Same application but if a setTimeout, of a variable time from 500ms to 4 seconds depending on the device, is used before the first call it does work.  This suggests that the stack is smaller on startup for some reason and then becomes available later?  

Could this be something that is caused by the JITing/tiered JITing of the WebAssembly module when loading?  The stack that is available is being used by the compilation of the WebAssembly module and then freed back up again?

Is this controllable somehow?  Maybe some type of signal that says the WebAssembly module has finished doing what it is doing on mobile devices and can be called into now.  Other than onRuntimeIntialized of course as we are using that to start up the app now.

Which stack is actually exceeded to be exact.  Is it the JavaScript stack depth or the WebAssembly stack depth?

We get the same information for the different stack sizes reported no matter what browser we use.  For example:

 WASM: TOTALMEMORY: 33554432 TOTALSTACK: 5242880 STACKMAX: 726800 STACKTOP: 5969680 STACKBASE: 5969680

The above line is exactly the same across all browsers including safari desktop yet we are running into some limit on mobile safari but not sure exactly where.

Any information on the above would be greatly appreciated.

Thanks in advance.

-- 
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/20191021/7f32c513/attachment.html>