Report load/store address and memory size on out-of-bounds memory traps

[fitzgen]

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?

[bjorn3]

trap address = 999999

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

[peterhuene]

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

[cfallin]

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.

[fitzgen]

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.

[fitzgen]

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.