At Wikipedia we use an emscripten-based decoder in Safari for some video and audio formats, and are looking at deploying a WebAssembly build for both desktop and mobile. In iOS 11.2.2 there's a major regression in wasm which breaks things with "out of bounds memory access" errors, which I believe is rdar:://problem/36236004 and supposed to be fixed; however the latest version I can test is iOS 11.2.5beta 6, where instead of emitting an error the entire web content process hangs without emitting any console messages. Sample using asm.js build: * https://brionv.com/misc/ogv.js/demo/#player=js ^ works Sample using wasm build: * https://brionv.com/misc/ogv.js/demo/#player=wasm ^ errors out on 11.2.2, hangs on 11.2.5b6 The hang comes during initialization or early execution, making it tricky to connect with the Safari remote debugger. Downstream issues: * https://phabricator.wikimedia.org/T179108 * https://github.com/brion/ogv.js/issues/485 * https://github.com/kripken/emscripten/issues/6042
<rdar://problem/36631309>
11.2.5 beta 7 on iPad Pro 9.7" no longer seems to hang the web content process; I get the original out of bounds memory access error, now caught by surrounding code and logged internally as opposed to outputting direct to console: [Log] [3395ms] i/o error: Error: Out of bounds memory access (evaluating 'Module["asm"]["_ogv_demuxer_receive_input"].apply(null,arguments)') (ogv.js, line 1005)
I've identified a smaller test case which I've posted at https://github.com/brion/min-wasm-fail Does an i32.store of a value at index 4 and reads it back -- on iOS I get 0 instead of the expected value. (At index 0, we get the expected value back.) The actual out of bounds exception in emscripten'd code seems to be a side effect of failing to load/store correctly, so pointers get screwed up and something ends up trying to access outside of mem.
Confirmed resolved in iOS 11.3 beta 1.
*** Bug 181598 has been marked as a duplicate of this bug. ***
For those of us who can't see rdar links, is there any news on this?
(In reply to Ashley Gullen from comment #6) > For those of us who can't see rdar links, is there any news on this? Bug is resolved in iOS 11.3 betas; presumably the fix won't reach the public until 11.3 is complete, so for now people will need to detect the bug and either throw a user-visible error or switch to an asm.js build. I've created a small test case at https://github.com/brion/min-wasm-fail/blob/master/min-wasm-fail.js which can be used to check at runtime whether the bug is present, which I've integrated into my project. Please feel free to copy that test case.
OK, thanks. Is there any indication when 11.3 is due out? We can hack in a workaround but it won't fix all the content that's already been deployed with our software. I can't believe that a key web technology is completely broken and it's being left like that!
I'm sure the Apple folks can't comment on that, but what indications I have seen in public are "spring" which could mean anywhere from March to May of this year. I would love an earlier fix on the 11.2.x branch too, but I know engineering scheduling is a hard problem...
Wow. Okay. Seriously, it would have been better to simply turn off WebAssembly, so existing fallbacks to asm.js are activated.
WebAssembly is still enabled, and non-functional, on iOS 11.2.6.
I think there is no fundamental improvement for this issue, because I have tested it on all kinds of iOS version from 11.0.1 to 11.3 b6, only 11.2.1 can work well so far, I have submitted related issues but the issues' status all are "NEW". Please refer to: https://bugs.webkit.org/show_bug.cgi?id=181723 https://bugs.webkit.org/show_bug.cgi?id=183101 https://github.com/kripken/emscripten/issues/6042 https://forum.unity.com/threads/webgl-builds-crash-issue-on-ios-browsers-unity3d.518240/ I think apple/webkit should face this issue seriously and fix it ASAP, this issue should be reopened. Thanks!