181723 2018-01-17 03:07:50 -0800 REGRESSION (iOS 11.2.2): Unhandled Promise Rejection: Error: Out of executable memory in function at index 2020-01-15 17:38:56 -0800 1 1 1 Unclassified WebKit WebAssembly Safari 11 iPhone / iPad iOS 11 REOPENED InRadar P2 Major --- 1 shader.yang webkit-unassigned alonzakai annulen ap evan.exe fpizlo jfbastien jujjyl keith_miller m morten.sorvig saam walter webkit-bug-importer oldest_to_newest 1389950 0 shader.yang 2018-01-17 03:07:50 -0800 Steps: 1. open Safari on iOS 11.2.2/11.2.5 beta5 2. access link: https://www.mujigame.com/games/muji/ws22 Expected: The page can be opened and wasm runs well. Actual: Get Unhandled Promise Rejection: Error: Out of executable memory in function at index exception. More information: This issue is also found on wkwebview on iOS 11.2.2/11.2.5 beta5 And the same discussion can be referred to: https://forum.unity.com/threads/webassembly-no-longer-working-on-ios-11-2-2.511905/ https://github.com/kripken/emscripten/issues/6042 1409499 1 keith_miller 2018-03-27 02:19:09 -0700 This issue is likely because we generate more code in our changes to mitigate Spectre and run out of executable memory. There isn't a quick solution to this on our end, unfortunately. 1410239 2 shader.yang 2018-03-29 06:12:21 -0700 (In reply to Keith Miller from comment #1) > This issue is likely because we generate more code in our changes to > mitigate Spectre and run out of executable memory. There isn't a quick > solution to this on our end, unfortunately. Got it, thanks! 1410244 3 shader.yang 2018-03-29 07:06:50 -0700 (In reply to Keith Miller from comment #1) > This issue is likely because we generate more code in our changes to > mitigate Spectre and run out of executable memory. There isn't a quick > solution to this on our end, unfortunately. And more question, do you know whether this issue https://bugs.webkit.org/show_bug.cgi?id=183101 is related to Spectre patch too? Thanks! 1464339 4 morten.sorvig 2018-09-28 00:53:53 -0700 Would it be possible to increase the size of the executable memory pool for iOS devices? The code in ExecutableAllocator.cpp suggests a current size of 64MB for ARM64: #if defined(FIXED_EXECUTABLE_MEMORY_POOL_SIZE_IN_MB) && FIXED_EXECUTABLE_MEMORY_POOL_SIZE_IN_MB > 0 static const size_t fixedExecutableMemoryPoolSize = FIXED_EXECUTABLE_MEMORY_POOL_SIZE_IN_MB * 1024 * 1024; #elif CPU(ARM) static const size_t fixedExecutableMemoryPoolSize = 16 * 1024 * 1024; #elif CPU(ARM64) static const size_t fixedExecutableMemoryPoolSize = 64 * 1024 * 1024; #elif CPU(X86_64) static const size_t fixedExecutableMemoryPoolSize = 1024 * 1024 * 1024; #else static const size_t fixedExecutableMemoryPoolSize = 32 * 1024 * 1024; #endif 1464871 5 saam 2018-09-30 11:40:37 -0700 Is this still an issue in iOS 12? The link reported here doesn't seem to do anything anymore. 1464959 6 morten.sorvig 2018-10-01 05:03:19 -0700 I can still reproduce this on 12.0 (16A366), using this test case: https://msorvig.github.io/qt-webassembly-examples/slate/slate.html 1469115 7 saam 2018-10-14 21:04:33 -0700 We bumped the space to 128MB recently (in ToT WebKit). That will probably make this test case work. Marking as configuration changed for now. 1471231 8 walter 2018-10-22 09:05:35 -0700 Looks like the change was reverted: https://bugs.webkit.org/show_bug.cgi?id=190453 If you need a new test case, I've made one here: http://packages.kognito.com/Safari_iOS_WASM_Bug (this loads on Safari/Edge/Chrome/Firefox on the "Desktop platform" and Chrome/Firefox on the "Android Platform"). 1499101 9 walter 2019-01-28 11:22:59 -0800 Hello, iOS 12.2 has the configuration change this ticket references (https://bugs.webkit.org/show_bug.cgi?id=190453) that was hopefully going to resolve this issue, but unfortunately it still exists. What are the next steps? Can I provide you with any more information or test cases? 1499609 10 annulen 2019-01-29 11:10:08 -0800 Reopening because of report by Walter Stumpf above 1499679 11 walter 2019-01-29 13:21:32 -0800 Okay apologies for not conducting a full review with iOS 12.2! So TLDR: I would rate this ticket as 99% resolved. In some various use cases this exact error can still happen (e.g. loading our Unity wasm app, navigating to a new page, when navigating back to the original page our app will often trigger this error on second load). But on a newly opened tab, our Unity app can consistently load. I'd still rate the behavior on 11.2.1 as more robust, but I think we can still work with the current implementation in 12.2. I apologize again for the confusion. Thanks again for the help, you've made every Unity webgl developer happy! 1504787 12 saam 2019-02-10 20:22:26 -0800 This probably won't be fully resolved until we implement an interpreter. But it might be worth looking into if we could try to GC to delete old code before throwing this exception. 1504790 13 webkit-bug-importer 2019-02-10 20:23:44 -0800 <rdar://problem/47954056> 1548540 14 m 2019-06-27 11:09:07 -0700 It seems that the issue came back with the new iPadOS update. I checked few pages which worked on iOS 12 and they throw "Error: Out of executable memory in function at index" exceptionon on iPadOS 13 beta 2. 1560444 15 walter 2019-08-12 09:59:05 -0700 I can confirm on iPad OS (beta 6) this bug is back. :( I have not tried iOS 13 on my iPhone yet, but on a fresh tab our wasm application (Unity game) cannot load on my iPad Pro. 1560810 16 ap 2019-08-13 09:17:21 -0700 Please file new bugs with repro steps for the regressions seen in iOS 13 beta. An old bug that isn't fully resolved shouldn't be conflated with cases that used to work, but no longer do. 1560922 17 walter 2019-08-13 13:04:47 -0700 No worries I made one here: https://bugs.webkit.org/show_bug.cgi?id=200686 1598916 18 jujjyl 2019-12-16 09:03:16 -0800 Running Unity content http://clb.confined.space/dump/WebGL1-2019-12-11/ on Safari 12.1.1 on iPad Pro 2018 on iOS 12.3.1 works ok, but running the same page on Safari 13.0.3 on iPhone Xs on iOS 13.2.0 runs out of memory. The communication trail at https://bugs.webkit.org/show_bug.cgi?id=200686 and https://bugs.webkit.org/show_bug.cgi?id=200807 suggests this bug would be fixed, though testing above page suggests that is not the case.