Stream: git-wasmtime

Topic: wasmtime / issue #3120 Report load/store address and memo...

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:30):

fitzgen opened issue #3120:

Feature

When a Wasm program traps due to an out-of-bounds memory access, report the address that the Wasm attempted to access and the memory size.

Benefit

This will make debugging such bugs much easier.

Implementation

We can get the faulting address via si_addr which I thiiiink is all we need. Wasm can't access two different memories with the same native address (or else what should have been a trap for one memory might accidentally succeed in accessing a different memory) so guard pages should always be associated with one particular memory. We just have to grab the current instance, iterate over its memories and find which one this guard page is associated with. Once we have that, we do a little arithmetic to translate the native address to a Wasm address.

Hopefully mach ports give us similar info. Completely unsure about windows. This seems like the kind of thing where it isn't the end of the world if we only get this info on some platforms, since it is just a debugging helper.

When we are using explicit bounds checks, it seems like we can just emit code to embed this data into the trap directly.

Alternatives

Build valgrind-esque tooling into Wasmtime? Add a mode to trace all heap accesses before we actually do the access and potentially trap?

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:30):

fitzgen labeled issue #3120:

Feature

When a Wasm program traps due to an out-of-bounds memory access, report the address that the Wasm attempted to access and the memory size.

Benefit

This will make debugging such bugs much easier.

Implementation

We can get the faulting address via si_addr which I thiiiink is all we need. Wasm can't access two different memories with the same native address (or else what should have been a trap for one memory might accidentally succeed in accessing a different memory) so guard pages should always be associated with one particular memory. We just have to grab the current instance, iterate over its memories and find which one this guard page is associated with. Once we have that, we do a little arithmetic to translate the native address to a Wasm address.

Hopefully mach ports give us similar info. Completely unsure about windows. This seems like the kind of thing where it isn't the end of the world if we only get this info on some platforms, since it is just a debugging helper.

When we are using explicit bounds checks, it seems like we can just emit code to embed this data into the trap directly.

Alternatives

Build valgrind-esque tooling into Wasmtime? Add a mode to trace all heap accesses before we actually do the access and potentially trap?

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:30):

fitzgen labeled issue #3120:

Feature

When a Wasm program traps due to an out-of-bounds memory access, report the address that the Wasm attempted to access and the memory size.

Benefit

This will make debugging such bugs much easier.

Implementation

We can get the faulting address via si_addr which I thiiiink is all we need. Wasm can't access two different memories with the same native address (or else what should have been a trap for one memory might accidentally succeed in accessing a different memory) so guard pages should always be associated with one particular memory. We just have to grab the current instance, iterate over its memories and find which one this guard page is associated with. Once we have that, we do a little arithmetic to translate the native address to a Wasm address.

Hopefully mach ports give us similar info. Completely unsure about windows. This seems like the kind of thing where it isn't the end of the world if we only get this info on some platforms, since it is just a debugging helper.

When we are using explicit bounds checks, it seems like we can just emit code to embed this data into the trap directly.

Alternatives

Build valgrind-esque tooling into Wasmtime? Add a mode to trace all heap accesses before we actually do the access and potentially trap?

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:33):

fitzgen edited issue #3120:

Feature

When a Wasm program traps due to an out-of-bounds memory access, report the address that the Wasm attempted to access and the memory size, eg:

wasm trap: out of bounds memory access
    memory size (bytes) = 65536
    trap address = 999999

Benefit

This will make debugging such bugs much easier.

Implementation

We can get the faulting address via si_addr which I thiiiink is all we need. Wasm can't access two different memories with the same native address (or else what should have been a trap for one memory might accidentally succeed in accessing a different memory) so guard pages should always be associated with one particular memory. We just have to grab the current instance, iterate over its memories and find which one this guard page is associated with. Once we have that, we do a little arithmetic to translate the native address to a Wasm address.

Hopefully mach ports give us similar info. Completely unsure about windows. This seems like the kind of thing where it isn't the end of the world if we only get this info on some platforms, since it is just a debugging helper.

When we are using explicit bounds checks, it seems like we can just emit code to embed this data into the trap directly.

Alternatives

Build valgrind-esque tooling into Wasmtime? Add a mode to trace all heap accesses before we actually do the access and potentially trap?

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:34):

bjorn3 commented on issue #3120:

trap address = 999999

I think it should be a hex address. That is how pointers are often shown.

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:45):

peterhuene commented on issue #3120:

We should also be able to report if the access was a read vs. a write.

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:45):

cfallin commented on issue #3120:

This is a great idea!

One possible complication is what to do about memories with explicit bounds-checks (and no or minimal guard regions); in such a case, the generated code contains a compare/branch and an explicit trap instruction in the failing case. It should be reasonable to add a register argument to the trap instruction to provide the faulting address (Wasm or native) in a fixed register, though; then we could grab this from the signal machine context in the same way we get PC, etc.

Wasmtime GitHub notifications bot (Jul 27 2021 at 17:46):

fitzgen commented on issue #3120:

I thiiink with mach ports we want the faultvaddr field of the <arch>_exception_state_t struct, which can be grabbed via thread_get_state.

Wasmtime GitHub notifications bot (Jul 28 2021 at 18:21):

fitzgen commented on issue #3120:

Oh, we should also report the memory index.

The root cause of the bug that I was debugging and was annoyed with how little info I had, prompting me to open this issue, was that I was accessing the wrong memory.

Last updated: Oct 23 2024 at 20:03 UTC