Stack corruption in a concurrent suspension/unsuspension scenario

[mboc-qt]

Version of emscripten/emsdk:
3.1.44

Failing command line in full:
make && cd build && emrun main.html

Full link command and output with -v appended:
See Makefile

When an operation from a dynamic callback is unsuspended, and the code originating at main() has been suspended and unsuspended in the meantime, the stack gets corrupted.
To reproduce, simply run the program as specified in the 'failing command line' section. You should be seeing an error in the console after 5 seconds - the test map in timer callback seems to have been somehow meddled with.
This only happens if the loop in the code is outside of the suspended method for some reason - see the comments in code.

suspend.zip

[sbc100]

My understanding is that with -sASYNCIFY ( which I assume is what you are talking about here) you can only have at most one suspended operation at a time.

@kripken @brendandahl , I wonder if we can detect when a second suspend is attempted and error out in debug builds.

[kripken]

We should already have such assertions. @mboc-qt do you see an error in a debug build? (-O0, or manually add -sASSERTIONS)

[mboc-qt]

This is about JSPI (ASYNCIFY=2), which in my understanding should support that?

[brendandahl]

JSPI still has the same re-entrancy problems as ASYNCIFY=1. We don't have any assertions to guard against reentrancy with JSPI right now.

We've talked of trying to make re-entrancy safer by storing the shadow stack and stack pointer, but I haven't looked into how hard that will be or if it's even possible.

[sbc100]

Would be hard to add the assertions in JSPI mode?

[brendandahl]

To clarify, JSPI + wasm supports reentrancy, but the C++ we generate is not reentrant safe.

[brendandahl]

Would be hard to add the assertions in JSPI mode?

I think it would be pretty easy, we just need to check if there's already a global suspender. IIRC though, asyncify=1 does support some reentrancy if your code doesn't use the shadow stack. I need to research again.

[sbc100]

Would be hard to add the assertions in JSPI mode?

I think it would be pretty easy, we just need to check if there's already a global suspender. IIRC though, asyncify=1 does support some reentrancy if your code doesn't use the shadow stack. I need to research again.

Sounds dangerous enough that we would still want assert-by-default anyway, perhaps with an option to ignore at your own risk?

[mboc-qt]

I would greatly recommend (and be grateful for) attempting to make it possible with JSPI. It's a fairly common scenario to have an event loop with a suspend/wake up routine and parallel suspends in web event callbacks.

[laminowany]

I agree that this is a quite common scenario and making it work with JSPI would be great!

[sbc100]

Don't all the same arguments also apply to regular -sASYNCIFY?

Do we have a feature request open for this? If not, perhaps we should open one?

[msorvig]

I think the arguments apply for asyncify 1 as well. I filed #10375 some time ago, maybe it can be re-opened? (closed by the bot)