Crashes / misexecutions or miscompilations with growable memory and atomics about emscripten

[Ono-Sendai]

Example 1: jrouwe/JoltPhysics#929
Example 2: jrouwe/JoltPhysics#952

[kripken]

There are no known issues in that area. To investigate this we'd need a small testcase.

However, first thing I would try some debug tools that can catch common errors, like sanitizers. Some compiler settings can help too.

[Ono-Sendai]

Are you suggesting running the program with a sanitizer in the browser?
I don't think it will help anyway.
I'll make a test case for you. I'm pretty sure it's not a problem with my c++ code or Jolt's C++ code btw, it's most likely an emscripten problem.

[sbc100]

A test would be great, the smaller the better.

We do have a lot of tests for basic usage of threads and atomics, including with memory growth, but you could be using something in a way that we don't have coverage for yet.

Can you share the full set of link flags you are using?

If possible, can you narrow down the those flags to just ones needed to reproduce crash? For example can you confirm for sure if removing memory growth makes the problem go away?

What kind of atomics are you using? e.g. are you using basic C _Atomic or something higher level?

[kripken]

Are you suggesting running the program with a sanitizer in the browser?

Yes, that is what I was suggesting. It's usually very simple to do, just add -fsanitize=address for example in your compile and link stages, and then run the application normally. Sanitizer errors then show up in the dev console. It's a quick and easy way to make sure there is no memory corruption.

[Ono-Sendai]

Are you suggesting running the program with a sanitizer in the browser?

Yes, that is what I was suggesting. It's usually very simple to do, just add -fsanitize=address for example in your compile and link stages, and then run the application normally. Sanitizer errors then show up in the dev console. It's a quick and easy way to make sure there is no memory corruption.

Nice idea but address sanitizer is just running out of memory:

==42==ERROR: AddressSanitizer: out of memory: allocator is trying to allocate 0x295800 bytes

[Ono-Sendai]

Actually what I am seeing now with memory growth is table index out of bounds errors, for example:

gui_client.js:2908 Uncaught RuntimeError: table index is out of bounds
    at gui_client.wasm.__cxxabiv1::scan_eh_tab(/__cxxabiv1::(anonymous namespace)::scan_results&, _Unwind_Action, bool, _Unwind_Exception*, _Unwind_Context*) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.__gxx_personality_wasm0 (gui_client.wasm:0x56ae1d)
    at gui_client.wasm._Unwind_CallPersonality (gui_client.wasm:0x56b60f)
    at gui_client.wasm.OpenGLEngine::getProgramWithFallbackOnError(/ProgramKey const&) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.OpenGLEngine::assignShaderProgToMaterial(/OpenGLMaterial&, bool, bool, bool, bool) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.OpenGLEngine::buildObjectData(/Reference<GLObject> const&) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.OpenGLEngine::addObject(/Reference<GLObject> const&) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.GUIClient::loadPresentObjectGraphicsAndPhysicsModels(/WorldObject*, Reference<MeshData> const&, Reference<PhysicsShapeData> const&, int, int) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.GUIClient::loadModelForObject(/WorldObject*) (http://localhost/webclient/gui_client.wasm)
    at gui_client.wasm.GUIClient::checkForLODChanges(/) (http://localhost/webclient/gui_client.wasm)

[Ono-Sendai]

Actually all kinds of errors, when memory growth is enabled:
gui_client.js:2908 Uncaught RuntimeError: memory access out of bounds

(None of which happen without memory growth)

[Ono-Sendai]

I haven't manage to write a simple test case yet. Not sure what the magic ingredient is that is needed.