Stream: git-wasmtime

Topic: wasmtime / issue #4812 x64: Segfaulting rip-relative load...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 03:27):

alexcrichton labeled issue #4812:

Local bisection points to #4730 for this issue but that seems like it may also be just as likely to expose a preexisting issue. Reproducing this is somewhat nontrivial and wasm-tools shrink was pretty unsuccessful on this test case.

Using this input test case on an x86_64 machine this crash can be reproduced with:

$ cargo run -q \
  run foo.wasm \
  --wasm-features all \
  --enable-cranelift-nan-canonicalization \
  --wasm-timeout 20 \
  -g
zsh: segmentation fault  cargo run -q run $HOME/foo.wasm --wasm-features all  --wasm-timeout 20     -g

Note that this reproduction is quite specific to layout of code and the various options enabled here are all required with the input wasm above.

cc @elliottt

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 03:27):

alexcrichton opened issue #4812:

Local bisection points to #4730 for this issue but that seems like it may also be just as likely to expose a preexisting issue. Reproducing this is somewhat nontrivial and wasm-tools shrink was pretty unsuccessful on this test case.

Using this input test case on an x86_64 machine this crash can be reproduced with:

$ cargo run -q \
  run foo.wasm \
  --wasm-features all \
  --enable-cranelift-nan-canonicalization \
  --wasm-timeout 20 \
  -g
zsh: segmentation fault  cargo run -q run $HOME/foo.wasm --wasm-features all  --wasm-timeout 20     -g

Note that this reproduction is quite specific to layout of code and the various options enabled here are all required with the input wasm above.

cc @elliottt

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 05:28):

elliottt commented on issue #4812:

When I run the test case I get the following output:

% cargo run -q run ./foo.wasm --wasm-features all --enable-cranelift-nan-canonicalization --wasm-timeout 20 -g
Error: failed to run main module `./foo.wasm`

Caused by:
    0: failed to instantiate "./foo.wasm"
    1: wasm trap: integer overflow
       wasm backtrace:
           0:   0x61 - <unknown>!<wasm function 1>

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 05:35):

elliottt commented on issue #4812:

I thought to try your example on cee4b209f346ea279490268fe434dc52d0e0680c (the commit where #4730 was merged) and it did indeed segfault. Could the behavior I'm seeing on main be due to the fix for #4761 that was fixed in #4790?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 13:44):

alexcrichton commented on issue #4812:

Oh you know it was probably something to do with --disable-cache where my bisection went awry. I always forget to pass that flag, alas!

In that case yeah it looks like this is fixed locally so I'll close.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 13:44):

alexcrichton closed issue #4812:

Local bisection points to #4730 for this issue but that seems like it may also be just as likely to expose a preexisting issue. Reproducing this is somewhat nontrivial and wasm-tools shrink was pretty unsuccessful on this test case.

Using this input test case on an x86_64 machine this crash can be reproduced with:

$ cargo run -q \
  run foo.wasm \
  --wasm-features all \
  --enable-cranelift-nan-canonicalization \
  --wasm-timeout 20 \
  -g
zsh: segmentation fault  cargo run -q run $HOME/foo.wasm --wasm-features all  --wasm-timeout 20     -g

Note that this reproduction is quite specific to layout of code and the various options enabled here are all required with the input wasm above.

cc @elliottt

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 17:20):

alexcrichton reopened issue #4812:

Local bisection points to #4730 for this issue but that seems like it may also be just as likely to expose a preexisting issue. Reproducing this is somewhat nontrivial and wasm-tools shrink was pretty unsuccessful on this test case.

Using this input test case on an x86_64 machine this crash can be reproduced with:

$ cargo run -q \
  run foo.wasm \
  --wasm-features all \
  --enable-cranelift-nan-canonicalization \
  --wasm-timeout 20 \
  -g
zsh: segmentation fault  cargo run -q run $HOME/foo.wasm --wasm-features all  --wasm-timeout 20     -g

Note that this reproduction is quite specific to layout of code and the various options enabled here are all required with the input wasm above.

cc @elliottt

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 17:23):

alexcrichton commented on issue #4812:

According to oss-fuzz the original test case here still crashes and trying again locally I'm able to reproduce:

$ cargo run -q run --disable-cache testcase42.wasm --wasm-features all --cranelift-set wasmtime_linkopt_padding_between_functions=1
zsh: segmentation fault  cargo run -q run --disable-cache testcase42.wat --wasm-features all

with testcase42.wasm.gz as an input. This is probably related to the wasmtime_linkopt_padding_between_functions option which is pretty nonstandard and only there for the fuzzers, but it may mean that there's a missing alignment calculation for when a function starts?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 17:23):

alexcrichton commented on issue #4812:

Oh and to log, the reproduction for me locally is on 1a59b3e6c65cdc6510c6c9e98dd694a5a2e85a2d which should be main as of this writing

view this post on Zulip Wasmtime GitHub notifications bot (Aug 30 2022 at 18:54):

elliottt commented on issue #4812:

It's definitely coming from the fcopysign lowering:

% lldb -- cargo run -q run --disable-cache testcase42.wasm --wasm-features all --cranelift-set wasmtime_linkopt_padding_between_functions=1
...
Process 3067456 stopped

* thread #1, name = 'wasmtime', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007ffff6c57b3b
->  0x7ffff6c57b3b: andnps 0x24ef(%rip), %xmm6
    0x7ffff6c57b42: andps  %xmm3, %xmm4
    0x7ffff6c57b45: orps   %xmm4, %xmm6
    0x7ffff6c57b48: movl   $0x4f000000, %edx         ; imm = 0x4F000000
(lldb) disassemble -e 0x7ffff6c57b50 -s 0x7ffff6c57b0b
    0x7ffff6c57b0b: jge    0x7ffff6c57b13
    0x7ffff6c57b11: ud2
    0x7ffff6c57b13: addl   $0x80000000, %edx         ; imm = 0x80000000
    0x7ffff6c57b19: movl   %edx, %eax
    0x7ffff6c57b1b: cvtsi2ss %rax, %xmm3
    0x7ffff6c57b20: movl   $0x80000000, %eax         ; imm = 0x80000000
    0x7ffff6c57b25: movd   %eax, %xmm4
    0x7ffff6c57b29: xorps  %xmm4, %xmm3
    0x7ffff6c57b2c: movl   $0x80000000, %r11d        ; imm = 0x80000000
    0x7ffff6c57b32: movd   %r11d, %xmm4
    0x7ffff6c57b37: movdqa %xmm4, %xmm6
->  0x7ffff6c57b3b: andnps 0x24ef(%rip), %xmm6
    0x7ffff6c57b42: andps  %xmm3, %xmm4
    0x7ffff6c57b45: orps   %xmm4, %xmm6
    0x7ffff6c57b48: movl   $0x4f000000, %edx         ; imm = 0x4F000000
(lldb) register read eax
     eax = 0x80000000
(lldb) register read rip
     rip = 0x00007ffff6c57b3b


Prelude> (0x24ef + 0x00007ffff6c57b3b) `divMod` 16
(8796083345922,10)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 21:41):

elliottt closed issue #4812:

Local bisection points to #4730 for this issue but that seems like it may also be just as likely to expose a preexisting issue. Reproducing this is somewhat nontrivial and wasm-tools shrink was pretty unsuccessful on this test case.

Using this input test case on an x86_64 machine this crash can be reproduced with:

$ cargo run -q \
  run foo.wasm \
  --wasm-features all \
  --enable-cranelift-nan-canonicalization \
  --wasm-timeout 20 \
  -g
zsh: segmentation fault  cargo run -q run $HOME/foo.wasm --wasm-features all  --wasm-timeout 20     -g

Note that this reproduction is quite specific to layout of code and the various options enabled here are all required with the input wasm above.

cc @elliottt

Last updated: Nov 22 2024 at 16:03 UTC