Search Issue Tracker
Fixed in 2020.1.X
Fixed in 2019.3.X
Votes
42
Found in
2019.2.0f1
2019.3
2020.1
Issue ID
1192963
Regression
No
[WebGL] Using XElement.Load(string uri) causes an uncaught abort exception when using dlopen() dynamic linking in Emscripten
How to reproduce:
1. Extract the user's attached "WebGLBuild.zip" archive
2. Open "index.html" in a browser
3. Observe the error thrown by the browser
Expected result: the WebGL build runs without throwing an exception
Actual result: an exception is thrown indicating that Emscripten's linking support is needed to use dlopen()
Reproducible with: 2019.2.0f1
Not reproducible with: 2018.4.12f1
Could not test with: 2017.4.33f1, 2019.2.1f1, 2019.2.10f1, 2019.3.0b8, 2020.1.0a9
Note: could not test on 2017.4.33f1 due to an immediate crash upon launching the project. Could not test on versions 2019.2.0a1 through 2019.2.0b10 due to various Console errors. Not reproducible on versions 2019.2.1f1 through 2019.2.10f1 and on the 2019.3 and 2020.1 streams due to the built project not loading (no error is thrown, either).
-
kove2727
Sep 14, 2023 13:02
Hi guys, I'm using unity 2020.3.29f1 still facing this issue. I tried installing unity 2019.1 to but solved Does Any body have solution to this ?
-
l0calhost
Apr 15, 2021 07:21
Still facing the same issue with Unity 2019.4.23f and Photon PUN 2. Thinking of downgrading one branch to 2019.1 just in case it works with the older version. This is frustrating.
-
StarArcher
Feb 04, 2021 15:22
I'm using Unity 2020.2.1f1 and when I turned on IL2CPP everything was fine for Android, but got the original poster's runtime error on WebGL: "to use dlopen, you need to use Emscripten's linking support".
I fixed this with a conditional compile. For example:
#if UNITY_WEBGL
[DllImport("__Internal")]
public static extern void arwSetLogLevel(int logLevel);
#else
[DllImport("scrBrowserScripting.jslib")]
public static extern void arwSetLogLevel(int logLevel);
#endifHope this saves some people some time :-)
Also, see this related thread: https://stackoverflow.com/questions/65853741/unity-android-build-works-in-mono-but-fails-in-il2cpp-due-to-undefined-reference/66048496#66048496
-
vrzone-io
Jul 17, 2020 14:56
Still happening in Unity 2019.3.1.15f1 while deploying on WebGL
[code=CSharp]Uncaught abort("To use dlopen, you need to use Emscripten's linking support, see https://github.com/kripken/emscripten/wiki/Linking") at Error
at jsStackTrace (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:22313)
at Object.stackTrace (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:22484)
at Object.onAbort (http://127.0.0.1:8000/Build/UnityLoader.js:4:11118)
at abort (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:557852)
at _dlopen (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:186247)
at <anonymous>:wasm-function[74483]:0x16b5f3e
at <anonymous>:wasm-function[75933]:0x16f5d68
at <anonymous>:wasm-function[66821]:0x14a1228
at <anonymous>:wasm-function[66993]:0x14a42ac
at <anonymous>:wasm-function[36156]:0xe47c6c
at <anonymous>:wasm-function[36154]:0xe46be4
at <anonymous>:wasm-function[36151]:0xe46adc
at <anonymous>:wasm-function[36150]:0xe464ee
at <anonymous>:wasm-function[29198]:0xd15526
at dynCall_iiiii (<anonymous>:wasm-function[77085]:0x172d911)
at Object.dynCall_iiiii (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:522390)
at invoke_iiiii (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:363788)
at <anonymous>:wasm-function[75093]:0x16d32b7
at <anonymous>:wasm-function[74403]:0x16b2aa4
at <anonymous>:wasm-function[5211]:0x249e9d
at <anonymous>:wasm-function[5210]:0x249dc6
at <anonymous>:wasm-function[8858]:0x388679
at <anonymous>:wasm-function[8855]:0x38749b
at <anonymous>:wasm-function[11318]:0x490583
at <anonymous>:wasm-function[9169]:0x3ae0f4
at <anonymous>:wasm-function[11703]:0x4bc8eb
at <anonymous>:wasm-function[11414]:0x499bc6
at <anonymous>:wasm-function[11414]:0x499bdb
at <anonymous>:wasm-function[11409]:0x4996e4
at <anonymous>:wasm-function[11402]:0x4976c3
at dynCall_v (<anonymous>:wasm-function[77111]:0x172ddc4)
at Object.dynCall_v (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:535693)
at browserIterationFunc (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:190486)
at Object.runIter (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:193547)
at Browser_mainLoop_runner (blob:http://127.0.0.1:8000/c9e045eb-6027-49e5-8d61-c2182c9a7b47:8:192009)[/code] -
kmilz
Jun 11, 2020 18:40
Experiencing issue with 2019.37f1, 2019.4.0f1 still not fixed
-
tokar_dev
Jun 05, 2020 08:44
Reproduced on:
EditorVersion: 2019.3.15f1
Windows NT 10.0; Firefox 78.0b2 (64-bit) -
tim_lol
Jun 03, 2020 15:32
This is still not fixed as of 2019.3.15 even though it says fixed in 2019.3 (and still says active also? That's weird). 2019.3.14 had this listed as a known issue in the patch notes, yet it was removed in 2019.3.15 patch notes but not fixed!
-
PeterDrake
May 22, 2020 16:23
This is also broken for me (2019.3.14f1).
-
Twyker_gp
May 15, 2020 21:13
Some help with this would be nice. Is happening when I use LZ4 compression in MessagePack.
-
peterdfinn
May 13, 2020 20:49
Having this issue in 2019.3.12f1.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on ScriptableRenderLoopDraw when rendering a specific VFX in Play Mode
- The script is not renamed in the Project window when renaming and a compilation Error is present
- Average FPS in Play Mode degradation on a newly created BiRP project when it's upgraded from 2020.3.48f1 to a newer Editor version
- DecoratorDrawer indentation is incorrect when it is called with EditorGUI
- "Unable to get the list of approved APIs." is thrown when testing the App Packages with Windows App Certification Kit
Resolution Note (fix version 2020.1):
The issue described in the original report appears when using XElement.Load(string uri) in WebGL build. XElement.Load(string uri) internally a calls System.Net.WebProxy.CreateDefaultProxy, which performs MacOS platform check. This MacOS platform check has been broken in WebGL around 2018.3, causing the mentioned "dlopen()" runtime error. The issue has been fixed in 2020.1.0a19 and the fix has been backported to 2019.3.0f6.
Note that even though the original issue has been fixed, XElement.Load(string uri) still can not work properly on WebGL. XElement.Load(string uri) relies on xml file being loaded synchronously from the web and therefore internally uses multi-threading functionality which is currently not supported on WebGL. Downloading a file synchronously without multi-threading is also not supported in WebGL because synchronous XMLHttpRequest is currently in a deprecation state. The workaround would be to download the xml file in advance (i.e. using UnityWebRequest) and then parse it directly from the string using XElement.Load(System.IO.TextReader textReader). This workaround also doesn't involve any MacOS platform checks which originally caused the mentioned "dlopen()" error.
Fixed in 2019.3.0f5, 2020.1.0a19, 2020.2.0a7