Do not clone stack frames if there's no trap #3008
Conversation
Yes, agree, it should be easier to expose issues, how about using |
| @@ -1924,7 +1924,8 @@ wasm_frame_func_offset(const wasm_frame_t *frame) | |||
| void | |||
| wasm_frame_vec_clone_internal(Vector *src, Vector *out) | |||
| { | |||
| bh_assert(src->num_elems != 0 && src->data); | |||
| if (src->num_elems == 0) | |||
| return; | |||
There was a problem hiding this comment.
Had better to bh_vector_destory(out) before return to free its possible frames and zero-initialize out? For example, an instance's frames may be created previously and then wasi_proc_exit occurs.
BTW, in L1932, seems no need to destroy out again if bh_vector_init fails?
There was a problem hiding this comment.
BTW, in L1932, seems no need to destroy out again if bh_vector_init fails?
Right, changed to make it similar to
eloparco
force-pushed
the
eloparco/fix-crash-when-trap-stack-trace-empty
branch
2 times, most recently
from
e32ff1c
to
0d6b30f
Compare
eloparco
force-pushed
the
eloparco/fix-crash-when-trap-stack-trace-empty
branch
from
0d6b30f
to
bcbb0df
Compare
…dealliance#3008) When running the wasi-threads no_pthread sample, the assert was failing on `src->num_elems != 0` in debug mode, it is because that the exception is `proc_exit`, there is no trap (the execution didn't fail, no stack frames): https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/samples/wasi-threads/wasm-apps/no_pthread.c
Follow-up on bytecodealliance#3008. Compiling samples in Debug mode allows us to take advantage of asserts and would have prevented the fix in bytecodealliance#3008.
When running the no_pthread sample, the assert was failing on
src->num_elems != 0.That's because, if the exception is
proc_exit, there's no trap (the execution didn't fail, no stack frames).The problem was not detected in CI because there we build in release mode:
wasm-micro-runtime/.github/workflows/compilation_on_macos.yml
Line 328 in 0844245
Should we use debug instead so that we can take advantage of asserts?