Stream: git-wasmtime

Topic: wasmtime / Issue #2582 Run Cranelift tests under Valgrind...


view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2021 at 03:03):

cfallin opened Issue #2582:

We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.

As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended on a subtle way on initial (undefined) register state. (Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because x == x always... except when x is NaN, hence nondeterministic failures.) Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2021 at 03:05):

cfallin edited Issue #2582:

We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.

As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended on a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because x == x always... except when x is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.

We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2021 at 03:08):

cfallin edited Issue #2582:

We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.

As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended in a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because x == x always... except when x is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.

We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2021 at 08:20):

julian-seward1 commented on Issue #2582:

For best avoidance of false positives, I'd suggest to use a snapshot of the trunk (git://sourceware.org/git/valgrind.git) if possible. Also, if you do find anything that looks like a false positive, do let me know .. the battle against them is ongoing.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 27 2021 at 16:06):

bnjbvr labeled Issue #2582:

We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.

As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended in a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because x == x always... except when x is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.

We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.


Last updated: Nov 22 2024 at 17:03 UTC