Stream: git-wasmtime

Topic: wasmtime / issue #4651 Question regarding wasmtime AOT co...

Wasmtime GitHub notifications bot (Aug 09 2022 at 04:29):

wilsonwang371 opened issue #4651:

Hi all,

I was running AOT code using wasmtime. However, my code generated a HeapOutOfBound trap and I need to find the root cause of this issue.

Currently, all that I can get is the AOT module & function line numbers information from which I can find out the original wasm module offset. However, I could not extract any more useful information. Is there any tips or suggestions about how to get more information out of the WASM state at the time of the trap?

Thanks

Wasmtime GitHub notifications bot (Aug 09 2022 at 14:28):

alexcrichton commented on issue #4651:

Whether or not the *.wasm is AOT compiled in theory shouldn't matter here. Wasmtime should be able to report the WebAssembly file offset of the trapping instruction, and if the original source module is compiled with debuginfo enabled in the *.wasm (this is distinct from debuginfo support in Wasmtime which is different) then Wasmtime should also print a backtrace on the trap with filenames/line numbers.

If you're not seeing this, though, could you compile the original *.wasm file with debug information?

Wasmtime GitHub notifications bot (Aug 10 2022 at 18:58):

wilsonwang371 commented on issue #4651:

Whether or not the *.wasm is AOT compiled in theory shouldn't matter here. Wasmtime should be able to report the WebAssembly file offset of the trapping instruction, and if the original source module is compiled with debuginfo enabled in the *.wasm (this is distinct from debuginfo support in Wasmtime which is different) then Wasmtime should also print a backtrace on the trap with filenames/line numbers.

If you're not seeing this, though, could you compile the original *.wasm file with debug information?

Hi Alex, thanks for reply. I found where the issue is. But I need to access the VM state(example, the stack top pointer and other related data values) to get a better understanding of why it is happening. Is there any way or is there any example code for me to follow?

Thanks

Wasmtime GitHub notifications bot (Aug 10 2022 at 19:03):

bjorn3 commented on issue #4651:

Do you mean the native stack pointer (this is stored in the same register as always), the emulated stack pointer of the wasm module (stored in a wasm global, which you can access through the vmcontext, which in turn is the last argument for function calls) or something else?

Wasmtime GitHub notifications bot (Aug 11 2022 at 06:59):

wilsonwang371 commented on issue #4651:

Do you mean the native stack pointer (this is stored in the same register as always), the emulated stack pointer of the wasm module (stored in a wasm global, which you can access through the vmcontext, which in turn is the last argument for function calls) or something else?

I mean the emulated stack pointer of wasm module. Yes. The vmcontext. How do i print them? Can you point out the place of the code that can help me print out the wasm module vmcontext when trap happens?

Wasmtime GitHub notifications bot (Aug 11 2022 at 07:04):

bjorn3 commented on issue #4651:

We don't currently generate debuginfo for this AFAIK, so you will have to manually locate where the vmcontext pointer is stored and at what offset in the vmcontext the global value is stored I think.

Wasmtime GitHub notifications bot (Aug 17 2022 at 17:06):

wilsonwang371 closed issue #4651:

Hi all,

I was running AOT code using wasmtime. However, my code generated a HeapOutOfBound trap and I need to find the root cause of this issue.

Currently, all that I can get is the AOT module & function line numbers information from which I can find out the original wasm module offset. However, I could not extract any more useful information. Is there any tips or suggestions about how to get more information out of the WASM state at the time of the trap?

Thanks

Last updated: Nov 22 2024 at 16:03 UTC