Hitting 'crash' in Emscripten/WASM usage about joltphysics HOT 10 CLOSED

Yes that is how I am working around it and how I worked out that this is likely the issue.
Please feel free to close the issue if you want, as this seems to be another emscripten / wasm bug.

from joltphysics.

Ok I guess this is what is happening: (from https://en.cppreference.com/w/cpp/thread/condition_variable/wait)

If these functions fail to meet the postconditions (lock.owns_lock()==true and lock.mutex() is locked by the calling thread), std::terminate is called. For example, this could happen if relocking the mutex throws an exception.

But of course in the Jolt code the lock is acquired immediately above the wait code, so I'm not sure what is going wrong.

std::unique_lock lock(mLock); mCount -= (int)inNumber; mWaitVariable.wait(lock, [this]() { return mCount >= 0; });

from joltphysics.

Hello,

I've not seen this crash before and it also doesn't make sense to me for the same reasons you mention. I'm guessing that it is not happening in the native version of your app or you would have created an issue sooner.

You could try commenting out the #ifdef JPH_PLATFORM_WINDOWS bits in the Semaphore class to make your Windows native app run the same code and check if you can repro the crash that way?

In any case I don't see any bugs mentioned in the emscripten issue trackers.

Maybe you can try another browser like Firefox (not Safari because that has issues with multithreading)?

from joltphysics.

Yeah it's just happening in Chrome currently.
Firefox fails for other reasons (hitting 2 GB mem usage with opengl calls fails), but seems to execute this code ok.

Do you have any more info about the Safari multithreading issues?

will try the JPH_PLATFORM_WINDOWS semaphore change on native.

from joltphysics.

Using condition_variable mWaitVariable on native Windows works fine (as expected).

from joltphysics.

Do you have any more info about the Safari multithreading issues?

See for example jrouwe/JoltPhysics.js#110 and #577

Luckily the issue seems to have been fixed in a recent development build of Safari.

Using condition_variable mWaitVariable on native Windows works fine (as expected).

A workaround that we could try is to make Linux/WASM use pthreads semaphores. Maybe those will work (at least they won't call std::terminate).

from joltphysics.

I'm hitting similar crashes in my non-Jolt code. So I even if I run Jolt with the single-threaded task manager, I still need to solve the issue. I think it's most likely miscompilation or misexecution of atomic variables, resulting in double-frees of reference-counted objects.

from joltphysics.

If you figure out what it is then I'd be curious to hear about it.

from joltphysics.

I have narrowed it down a little. Seems to be a combination of memory growth and atomics. Something like when the total amount of mem allocated to the WASM program (which I think takes the form of a single large buffer) increases, some atomic variable is accessed or changed incorrectly, leading to the 'crash'.

from joltphysics.

That makes sense, reallocation and atomics don't go together very well. But then you should be able to work around it by disabling memory growth -s ALLOW_MEMORY_GROWTH=0 and making sure that the initial memory block is large enough -s TOTAL_MEMORY=XXX (both parameters for emcc).

from joltphysics.