Stream: git-wasmtime

Topic: wasmtime / Issue #2270 get pc for freebsd

Wasmtime GitHub notifications bot (Oct 06 2020 at 17:27):

alexcrichton commented on Issue #2270:

Thanks for the PR! I think there's a rustfmt issue though?

Wasmtime GitHub notifications bot (Oct 07 2020 at 07:33):

subtly commented on Issue #2270:

Tests for other hosts pass, but 6 tests fail on freebsd. However, it seems this is backtrace-rs, as all failing tests rely on trace(), and 3 of the backtrace-rs tests fail.

    traps::present_after_module_drop
    traps::start_trap_pretty
    traps::test_trap_stack_overflow
    traps::test_trap_trace
    traps::trap_display_multi_module
    traps::trap_display_pretty

Example failure:
---- traps::start_trap_pretty stdout ----
thread 'traps::start_trap_pretty' panicked at 'assertion failed: `(left == right)`
  left: `"wasm trap: unreachable"`,
 right: `"wasm trap: unreachable\nwasm backtrace:\n  0:   0x1d - m!die\n  1:   0x21 - m!<wasm function 1>\n  2:   0x26 - m!foo\n  3:   0x2b - m!start\n"`', tests/all/traps.rs:409:5

backtrace-rs test:
running 1 test
test doit ... FAILED

failures:

---- doit stdout ----
-----------------------------------
looking for:
    tests/accuracy/main.rs:40
    crates/dylib-dep/src/lib.rs:11
    tests/accuracy/main.rs:39
found:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>

thread 'doit' panicked at 'failed to find tests/accuracy/main.rs:40', tests/accuracy/main.rs:104:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Wasmtime GitHub notifications bot (Oct 07 2020 at 11:30):

alexcrichton commented on Issue #2270:

Ok changes look good to me, thanks for this!

It's true yeah that trap stack traces won't work well if the backtrace crate doesn't work well, but unfortunately I don't have a FreeBSD machine to test changes on :(

Wasmtime GitHub notifications bot (Oct 07 2020 at 17:28):

subtly commented on Issue #2270:

Ok changes look good to me, thanks for this!

It's true yeah that trap stack traces won't work well if the backtrace crate doesn't work well, but unfortunately I don't have a FreeBSD machine to test changes on :(

I just set this up in arch linux with gcc and it fails the same 6 tests.

Want a machine to test on? Do you have macOS? I used xhyve and I think it can also be installed under qemu.

Wasmtime GitHub notifications bot (Oct 08 2020 at 21:14):

alexcrichton commented on Issue #2270:

Ah sorry I don't have time to dig in and investigate this either, but if you can try running cargo test on the backtrace crate you can see if it might succeed or not.

Wasmtime GitHub notifications bot (Oct 09 2020 at 10:06):

subtly commented on Issue #2270:

Ah sorry, I found the same wasmtime tests fail on Alpine Linux, not arch linux. All tests pass on Ubuntu 20.04. I just wanted to share the observation in case anyone runs into it later.

• all backtrace tests pass on Alpine Linux
• except 1 test on freebsd, backtrace tests pass on all (tested main and 0.3.50)
• notably, the test that fails on freebsd (doit) is disabled on Alpine Linux
• wasmtime tests fail on Alpine Linux, FreeBSD (same errors with traces)

I used LLVM linker for both Alpine and FreeBSD, although, I think the linker is actually supplied by rust? I think maybe the issue in wasmtime has to do with the program counter when getting frames, whereas with backtrace doit I suspect something quirky with libc::dlopen on that platform. I also read clang/llvm has its own unwind and looks like it can be compiled without it, and that could be it too. Guess I'll try and setup both OS with GCC now and see how it goes.

Last updated: Nov 22 2024 at 16:03 UTC