Deadlock in emscripten dynamic calls

[jcaesar]

Description

Attempting to run an emscripten-built rust module lead me to a deadlock. I'm not quite sure what's wrong, but it looks to me like emscripten is calling itself through the host (No idea why. To catch exceptions?) and in the process, wasmer acquires a lock that is still held when calling back into the module. If the module tries that twice recursively, the simplest form of deadlock, a reentrancy deadlock is triggered.

The standard library doesn't have reentrant locks.
This cannot be solved by replacing the lock on EmEnv.data by an RwLock, because the code might also call setTempRet0, which does require a write lock.
Maybe there is a way to get rid of the mutex entirely, but I do not see it.

The easy way out seems to be to clone the function (arcs), let go of the lock, and then do the call back into the module.

There are a few other instances of the same problematic pattern, but they call memset or malloc, which shouldn't call back into wasmer. I assume they are fine and left them alone, but have not done thorough testing.

Review

• Add a short description of the change to the CHANGELOG.md file

[Amanieu]

bors r+

[bors]

Build succeeded:

• Audit
• Code lint
• Test cross-compile on linux
• Test cross-compile on macos
• Test on linux-x64
• Test on macos-x64
• Test on windows-x64