Safari WebAssembly Unhandled Promise Rejection Error

2018.2.0f2 build doesn’t load on Safari when scene has a UI and any script calling UnityEngine.Animator on iOS 11.4.1 and 12 beta. 2018.1.7f1 wasm build seems to works fine. asm.js works with everything but we want to stick with the speedier wasm.

Attached Safari’s console output on the build:


I isolated the error on a new blank project with just a script on a cube and uploaded to with submitted bug report case 1058959.

 

It's a safari iOS bug with wasm, last working version was 11.2.1 or something. Too bad still broken with 12...

 

A new blank project loads fine. Only when using certain combinations of engine systems does it not load. Can we have someone at Unity look into this and at least tell us if there's anything they can do or if only Apple can fix this or not?

 

Only on iOS case 1058959

 

My only concern is @jonas-echterhoff linked this ticket (https://bugs.webkit.org/show_bug.cgi?id=181781) as being the culprit. However that ticket is now (and has been for some iOS versions) "fixed", yet our problem still remains. I doubt Unity can workaround the issue, but does Mozilla know about this bug and perhaps could workaround it in emscripten (a hail mary I know)?

 

This bug is now on Issue Tracker

https://issuetracker.unity3d.com/is...d-any-script-calling-unityengine-dot-animator

Please vote for this if you’re experiencing it. Thanks to Aurimas on the QA Team for looking into this. Hoping a solution or work-around can be found now.

 

Okay after some research I have some notes:

There was a bug with iOS Safari and wasm; that was resolved with 11.3 (https://bugs.webkit.org/show_bug.cgi?id=181781). This I believe is what we (the Unity community) thought was the "bug" preventing wasm from working with iOS Safari.

There's another bug with how Mozilla's emscripten expands the heap in wasm that in practice only effects iOS (https://github.com/kripken/emscripten/issues/6042), but they fixed it last week (obviously Unity has not integrated this fix). I'm not sure though that this is Unity's "problem". Theoretically if that was true, 2018.1 and before should "work" now right? I get the same "Unhandled promise rejection..." error with 2018.2 (that expands heap) and 2018.1 when loading our "normal binary". So I'm thinking a red herring? Maybe?

Finally, if I take the simple scene that I used for PVR testing (https://forum.unity.com/threads/sup...rmats-etc2-pvr-for-webgl.502382/#post-3583441) and use a 2018.2 binary with heap growth (that starts at 16 MB) I can actually successfully load the scene on iOS using wasm...most of the time (every once in awhile I do get the "Unhandled promise rejection..." error)! BUT, the character doesn't render (I even tried just using a simple unlit texture shader), only the lit skybox (so lighting at least works...). The same build works fine on desktop browsers and the asm.js version obviously works on iOS. The console log for the (non-working) wasm version is exactly the same as the (working) asm.js version.

So...I'm not really sure what to make of the "problem(s)". ¯\_(ツ)_/¯ But something fishy is going on with iOS + wasm + Unity.

 

So mozilla closed the issue: https://github.com/kripken/emscripten/issues/6042

Again I don't think this is "our" problem, but is there a way I could get the Unity editor to use a newer version of emscripten if I build it myself? Just replace the contents in "[Unity install location]\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\Emscripten"?

 

So I built emscripten from tip (using the SDK) and tried to replace all the files in:

• "[Unity install location]\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\Emscripten"
• "[Unity install location]\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\Emscripten_FastComp_Win"
• "[Unity install location]\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\Emscripten_Win"

I think I got most of it but I couldn't find a "binaryen.js" file and a corresponding "cache" folder for Emscripten_FastComp_Win (so I left them, hard to say if they were important). They also updated python from 2.7.5.3 to 2.7.13.1 (doubt it matters).

And...it worked(ish)!!!

Seems like Unity will always pass the parameter "--separate-asm" even when wasm only is selected. Perhaps this worked in the older version of emscripten, but this does not work with the new one (throws an error along the lines of "doesn't make sense when building for wasm only"). Also I could have screwed something up when copying and pasting files around.

However manually calling emcc with the commands Unity normally provides (minus --separate-asm) does seem to work! Tomorrow we test if I can actually run the build (and then on an iOS device)!

 

I've done a bit of tinkering with mixing Emscripten versions as well - you can patch out the flags Unity injects from the PlaybackEngines/WebGLSupport/UnityEditor.WebGL.Extensions.dll - found it easier than having to manually invoke emcc after making changes .

From what I remember I ran into some issues with how Unity initialised the wasm files against the latest version though so while it compiles you might have to do a bit more 'hacking' at the JS files to get it to actually load in the browser.

 

Yes editing the .dll worked (and it does seem like Unity blindly adds "--separate-asm" if "Use pre-Built Engine" is unchecked)!

And it also doesn't load. Amusingly I think the reason is printed in the screenshot I posted above. It's missing a symbol (_ZNSt3__212basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE7reserveEj) which causes an error of "missing function" from UnityLoader.js on load.

Making a development build fails due to the flag " -s ERROR_ON_UNDEFINED_SYMBOLS=1". Manually compiling without that flag produces the following warnings:



So after editing the .dll (again) to remove that flag we can make a (non-functioning) development build. That produces the error:

and the error handler:

This one might be difficult to figure out. Seems il2cpp related at first glance since it happens at compile time? I'll see if I can gather anymore clues.

 

On a more positive note, I noticed emscripten now auto-enables the other compressed texture formats (https://github.com/kripken/emscripten/pull/6942/commits/07f07e70e901585bcfd6e71f43995c31ed3662a0) and sure enough they do appear in the framework.unityweb file. If I can get this build to load (compile?) maybe I can kill two birds with one stone.

 

Found a little more time yesterday to investigate this a bit further. So I think the issue to my missing function is emscripten moved from t_Size to unsigned long (https://github.com/kripken/emscripten/pull/5916) which turned Znwj into Znwm. I suppose eventually Unity will have to deal with these changes. Unfortunately this was before the iOS changes I wanted to test. I'll see if 1) rolling back before this unsigned long commit let's me run Unity webgl again and if so if I can merge the iOS changes into that commit.

I think going back and changing all the Znwj references to Znwm will be too hard. Changing UnityNative.asm.js is easy enough but it looks like all the compiled modules (WebGLSupport_AccessibilityModule_Dynamic.bc, WebGLSupport_AIModule_Dynamic.bc, etc.) reference it too. Those may be beyond my power to recompile/change.

 

Hmm, any updates on this? I'm getting the same error on Safari on iOS13.1.x

 

https://forum.unity.com/threads/webgl-projects-not-loading-after-ios13-update.751736/

TLDR: Safari fixed it in iOS 12.2 and then broke it again in 13.x. They've fixed it in tip of webkit and the hope is 13.2 will once again resolve the issue.