Question regarding wasmtime AOT code panic debugging

[wilsonwang371]

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

[alexcrichton]

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?

[wilsonwang371]

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

[bjorn3]

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?

[wilsonwang371]

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?

[bjorn3]

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.