Stream: git-wasmtime

Topic: wasmtime / Issue #2470 Possible nondeterminism bug with S...


view this post on Zulip Wasmtime GitHub notifications bot (Dec 03 2020 at 15:11):

alexcrichton opened Issue #2470:

Recently a merged PR failed CI on master but then the next commit passed, so I'm curious if this might be an accidental bug in the new x64 backend? The errors unfortunately aren't the easiest to decipher, but wanted to open an issue to ensure we didn't lose this!

cc @abrown @jlb6740

view this post on Zulip Wasmtime GitHub notifications bot (Dec 03 2020 at 17:34):

cfallin commented on Issue #2470:

Hmm, thanks for reporting -- I think the best thing to do would be to disable the failing tests for now (simd_f32x4, simd_f32x4_arith, simd_f64x2_arith, simd_splat, simd_load from #2432). @abrown and @jlb6740 it might be worth running under Valgrind to find uninitialized value uses; this feels like it could be such an issue. I'll create a PR to disable the tests for now.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 03 2020 at 17:53):

jlb6740 commented on Issue #2470:

@cfallin hi yes .. this is tricky @abrown and I just talked about this. There is definitely something intermittent going on that seems to be occurring on those tests that use floating point ... so maybe affects tests that we've not seen failures in yet. I think @abrown was going to resurrect a pr to help print these values in a way that allows us to compare the expected output with the received output more cleanly but separately we were going to see if we can in a loop reproduce failures we've seen recently and running valgrind is definitely a great idea .. I will try that during investigation.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 03 2020 at 17:53):

jlb6740 edited a comment on Issue #2470:

@alexcrichton @cfallin hi yes .. this is tricky @abrown and I just talked about this. There is definitely something intermittent going on that seems to be occurring on those tests that use floating point ... so maybe affects tests that we've not seen failures in yet. I think @abrown was going to resurrect a pr to help print these values in a way that allows us to compare the expected output with the received output more cleanly but separately we were going to see if we can in a loop reproduce failures we've seen recently and running valgrind is definitely a great idea .. I will try that during investigation.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 04 2020 at 04:38):

abrown commented on Issue #2470:

Ok, I'm closing this in favor of https://github.com/bytecodealliance/wasmtime/issues/2432; lets make that the main tracking issue for these failures.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 04 2020 at 04:38):

abrown closed Issue #2470:

Recently a merged PR failed CI on master but then the next commit passed, so I'm curious if this might be an accidental bug in the new x64 backend? The errors unfortunately aren't the easiest to decipher, but wanted to open an issue to ensure we didn't lose this!

cc @abrown @jlb6740


Last updated: Nov 22 2024 at 16:03 UTC