Bug Defining a function with a two letter name in a .jslib may result in runtime error

Hi,
We have found an issue in WebGL were if we define a function inside a plugin .jslib file that has a two letter name, it may result in runtime error if that function name happens to be the same with any of the functions auto-generated inside wasm that are referenced by framework.js
If that actually occurs, we have seen that instead of the correct reference, it tries to reference a function that is defined in the key/value structure asmLibraryArg inside frameworks.js that references our own defined plugin function inside jslib.

e.g. in our case we had the Facebook SDK that had a function named "ui" that conflicted with the obfuscated function name "stackRestore" inside .wasm and resulted in runtime error:

build.loader.js:36 Invoking error handler due to

TypeError: stackRestore is not a function

We have been able to reproduce it also in an empty project with our own simple jslib file with a single two letter function.

Therefore, is this a bug of Unity/emscripten or is this a limitation that the developer needs to be aware of and not use short names for functions inside jslib files?

 

You can look at those function names as similar to C headers in a DLL.
And as all the headers in WebGL are imported using one endpoint, having the same name as other headers, in some cases can override existing function and on other can throw an error.

I think that best case would be to use a prefix representing the class, package or company this function is part of its code.

e.g. for a package of playing a video in WebGL by company Foo with a Play function, you can call it WebGLVideoPlay or FooWebGLVideoPlay.

It's long, but it can helps to make sure that other packages won't override the function by accident. (it can still happen intentionaly)

 

What you say makes perfect sense, and it is a good workaround. But could this have been caught during compilation by unity's building system?

Either as compilation error or actually handled, and using auto generated function names that don't collide with those used at libraries? A compilation error in my opinion would suffice.

The fact now, that we get a successful build that it is corrupted, is not optimal.