Do not fetch the next instruction when proc_exit is propagated

[eloparco]

Without the change in this PR, upon receiving the proc_exit exception propagation while on an atomic.atomic or poll_oneoff, the next instruction is fetched instead of stopping the executing.

That results in the exception being overridden (by an unreachable exception) when using the tests in https://github.com/WebAssembly/wasi-threads/tree/main/test/testsuite, causing the exit code to be wrong.
Continuation of #1929 #1951.

[wenyongh]

LGTM

[eloparco]

LGTM

Let me complete it before merging, it's not done yet since I need to fix AOT (and JIT as well probably).

Added a commit for that, but it doesn't work. Any suggestion for debugging AOT in general? Apart from adding some LLVMBuildCall only to pass parameters and print them at runtime.

This part is missing.

[wenyongh]

Had better not remove and modify to:

    bh_assert(wasm_get_exception(module_inst)
#if WASM_ENABLE_THREAD_MGR != 0
              || wasm_cluster_is_thread_terminated(exec_env_tls));
#endif
);

And also change the similar place for Windows (this file, L253):
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/common/wasm_runtime_common.c#L253

[eloparco]

Right, I'm debugging to understand why exec_env_tls->suspend_flags is not set properly once I get there.

[eloparco]

Ok, the problem was that we don't set the suspend flag for the thread that originally raises the exception. I pushed a fix but I noticed that it's breaking the spec tests. Any clue on what's breaking?

[eloparco]

The problem is that the assert would be executed also on the thread that originally raises the exception and that thread doesn't have the suspend flag set. I tried setting the suspend flag on that initial thread too but it break things since it forces the initial thread to exit prematurely (after a CHECK_SUSPEND_FLAGS();) while we don't want that.

So I was thinking of just having a

#if WASM_ENABLE_THREAD_MGR == 0
    bh_assert(wasm_get_exception(module_inst));
#endif

[wenyongh]

Not sure how to reproduce the issue? The thread_terminate sample with TEST_TERMINATION_BY_TRAP == 1 and TEST_TERMINATION_IN_MAIN_THREAD == 1?

[eloparco]

I think we may merge this PR firstly if you are OK and we will submit another PR to fix that issue.

Let's do it, so that I can move to #1985 that hopefully should succeed after we merge this.

[wenyongh]

@eloparco I tried again, and think this is not a best way to resolve the issue. The root cause is that the main thread's "wasi proc exit" exception is cleared by the sub thread after the latter gets the spread exception from main thread and then clear exception for all threads.
It is strange to spread the "wasi proc exit" exception to other threads and then clear it in other threads. I think we can just ignore spreading of this exception and no need to clear it again. I uploaded PR #1988 to fix the issues, I tested the cases and didn't find the issues you mentioned (unreachable exception was thrown and bh_assert failure), could you help review and try? Thanks.

[eloparco]

Can we merge this one and rebase #1988? So that it's easier to review. I'll then try #1988 in a few different cases to see if we don't have regressions.

[wenyongh]

My personal preference is we had better not merge a temporarily PR which doesn't fix the root cause, #1988 should be better and have resolved the issues mentioned in this PR. I tend to merge #1988 directly.

[eloparco]

Right, it makes sense. Let's close this one once #1988 gets merged

[eloparco]

Closing since the changes here have been applied to #1988