Stream: git-wasmtime

Topic: wasmtime / Issue #1716 Panic during module compile multi_...

Wasmtime GitHub notifications bot (May 15 2020 at 19:45):

plicease opened Issue #1716:

• What are the steps to reproduce the issue?

1. Adjust the multi.c example that comes with wasmtime #1715
2. compile and run on aarch64

pi1% env RUST_BACKTRACE=1 ./a.out
Initializing...
Compiling module...
thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
  12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs
  13: cranelift_codegen::machinst::lower::Lower<I>::lower
  14: cranelift_codegen::machinst::compile::compile
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
  16: cranelift_codegen::context::Context::compile
  17: cranelift_codegen::context::Context::compile_and_emit
  18: wasmtime_jit::compiler::make_trampoline
  19: wasmtime_jit::compiler::Compiler::compile
  20: wasmtime_jit::instantiate::CompiledModule::new
  21: wasmtime::module::Module::from_binary_unchecked
  22: wasmtime::module::Module::from_binary
  23: wasmtime_module_new
  24: main
  25: __libc_start_main
  26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 3705270992
Abort (core dumped)

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

Expect the program to run without fail as it does on x86_64. multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.

• Which Wasmtime version / commit hash / branch are you using?

This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

Raspberry Pi Ubuntu Focal

pi1% uname -a
Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.

Wasmtime GitHub notifications bot (May 15 2020 at 19:45):

plicease labeled Issue #1716:

• What are the steps to reproduce the issue?

1. Adjust the multi.c example that comes with wasmtime #1715
2. compile and run on aarch64

pi1% env RUST_BACKTRACE=1 ./a.out
Initializing...
Compiling module...
thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
  12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs
  13: cranelift_codegen::machinst::lower::Lower<I>::lower
  14: cranelift_codegen::machinst::compile::compile
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
  16: cranelift_codegen::context::Context::compile
  17: cranelift_codegen::context::Context::compile_and_emit
  18: wasmtime_jit::compiler::make_trampoline
  19: wasmtime_jit::compiler::Compiler::compile
  20: wasmtime_jit::instantiate::CompiledModule::new
  21: wasmtime::module::Module::from_binary_unchecked
  22: wasmtime::module::Module::from_binary
  23: wasmtime_module_new
  24: main
  25: __libc_start_main
  26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 3705270992
Abort (core dumped)

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

Expect the program to run without fail as it does on x86_64. multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.

• Which Wasmtime version / commit hash / branch are you using?

This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

Raspberry Pi Ubuntu Focal

pi1% uname -a
Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.

Wasmtime GitHub notifications bot (May 15 2020 at 20:04):

plicease edited Issue #1716:

• What are the steps to reproduce the issue?

1. Adjust the multi.c example that comes with wasmtime #1715
2. compile and run on aarch64

pi1% env RUST_BACKTRACE=1 ./a.out
Initializing...
Compiling module...
thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
  12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs
  13: cranelift_codegen::machinst::lower::Lower<I>::lower
  14: cranelift_codegen::machinst::compile::compile
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
  16: cranelift_codegen::context::Context::compile
  17: cranelift_codegen::context::Context::compile_and_emit
  18: wasmtime_jit::compiler::make_trampoline
  19: wasmtime_jit::compiler::Compiler::compile
  20: wasmtime_jit::instantiate::CompiledModule::new
  21: wasmtime::module::Module::from_binary_unchecked
  22: wasmtime::module::Module::from_binary
  23: wasmtime_module_new
  24: main
  25: __libc_start_main
  26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 3705270992
Abort (core dumped)

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.

• Which Wasmtime version / commit hash / branch are you using?

This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

Raspberry Pi Ubuntu Focal

pi1% uname -a
Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.

Wasmtime GitHub notifications bot (May 15 2020 at 20:54):

alexcrichton labeled Issue #1716:

• What are the steps to reproduce the issue?

1. Adjust the multi.c example that comes with wasmtime #1715
2. compile and run on aarch64

pi1% env RUST_BACKTRACE=1 ./a.out
Initializing...
Compiling module...
thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
  12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs
  13: cranelift_codegen::machinst::lower::Lower<I>::lower
  14: cranelift_codegen::machinst::compile::compile
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
  16: cranelift_codegen::context::Context::compile
  17: cranelift_codegen::context::Context::compile_and_emit
  18: wasmtime_jit::compiler::make_trampoline
  19: wasmtime_jit::compiler::Compiler::compile
  20: wasmtime_jit::instantiate::CompiledModule::new
  21: wasmtime::module::Module::from_binary_unchecked
  22: wasmtime::module::Module::from_binary
  23: wasmtime_module_new
  24: main
  25: __libc_start_main
  26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 3705270992
Abort (core dumped)

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.

• Which Wasmtime version / commit hash / branch are you using?

This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

Raspberry Pi Ubuntu Focal

pi1% uname -a
Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.

Wasmtime GitHub notifications bot (May 15 2020 at 20:55):

alexcrichton commented on Issue #1716:

I've only got access to an emulator, but if debug assertions are enabled it looks like there's a preceding problem which may be the root of the issue here:

thread '<unnamed>' panicked at 'assertion failed: rets.iter().all(|a| match a { &ABIArg::Stack(..) => false, _ => true, })', cranelift/codegen/src/isa/aarch64/abi.rs:225:9

(which is this line)

<details>

<summary>stack trace</summary>

thread '<unnamed>' panicked at 'assertion failed: rets.iter().all(|a| match a { &ABIArg::Stack(..) => false, _ => true, })', cranelift/codegen/src/isa/aarch64/abi.rs:225:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:397
  12: cranelift_codegen::isa::aarch64::abi::ABISig::from_func_sig
             at cranelift/codegen/src/isa/aarch64/abi.rs:225
  13: cranelift_codegen::isa::aarch64::abi::AArch64ABIBody::new
             at cranelift/codegen/src/isa/aarch64/abi.rs:372
  14: cranelift_codegen::isa::aarch64::AArch64Backend::compile_vcode
             at cranelift/codegen/src/isa/aarch64/mod.rs:49
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
             at cranelift/codegen/src/isa/aarch64/mod.rs:61
  16: cranelift_codegen::context::Context::compile
             at cranelift/codegen/src/context.rs:186
  17: cranelift_codegen::context::Context::compile_and_emit
             at cranelift/codegen/src/context.rs:132
  18: wasmtime_environ::cranelift::compile::{{closure}}
             at crates/environ/src/cranelift.rs:358
  19: core::ops::function::impls::<impl core::ops::function::Fn<A> for &F>::call
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ops/function.rs:242
  20: <rayon::iter::map_with::MapWithFolder<C,U,F> as rayon::iter::plumbing::Folder<T>>::consume_iter::with::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map_with.rs:317
  21: core::iter::adapters::map_try_fold::{{closure}}
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:779
  22: core::iter::traits::iterator::Iterator::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/traits/iterator.rs:1877
  23: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805
  24: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805
  25: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:1750
  26: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805
  27: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:1750
  28: core::iter::traits::iterator::Iterator::fold
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/traits/iterator.rs:2004
  29: <rayon::iter::fold::FoldFolder<C,ID,F> as rayon::iter::plumbing::Folder<T>>::consume_iter
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/fold.rs:158
  30: <rayon::iter::while_some::WhileSomeFolder<C> as rayon::iter::plumbing::Folder<core::option::Option<T>>>::consume_iter
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/while_some.rs:139
  31: <rayon::iter::map::MapFolder<C,F> as rayon::iter::plumbing::Folder<T>>::consume_iter
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map.rs:248
  32: <rayon::iter::map_with::MapWithFolder<C,U,F> as rayon::iter::plumbing::Folder<T>>::consume_iter
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map_with.rs:322
  33: rayon::iter::plumbing::Producer::fold_with
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:110
  34: rayon::iter::plumbing::bridge_producer_consumer::helper
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:438
  35: rayon::iter::plumbing::bridge_producer_consumer::helper::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:427
  36: rayon_core::join::join_context::call_b::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/join/mod.rs:130
  37: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::call::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:113
  38: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panic.rs:318
  39: std::panicking::try::do_call
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:303
  40: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:86
  41: std::panicking::try
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:281
  42: std::panic::catch_unwind
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panic.rs:394
  43: rayon_core::unwind::halt_unwinding
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/unwind.rs:17
  44: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:119
  45: rayon_core::job::JobRef::execute
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:59
  46: rayon_core::registry::WorkerThread::execute
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:681
  47: rayon_core::registry::WorkerThread::wait_until_cold
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:665
  48: rayon_core::registry::WorkerThread::wait_until
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:639
  49: rayon_core::registry::main_loop
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:759
  50: rayon_core::registry::ThreadBuilder::run
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:56
  51: <rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:101
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 42381904
qemu: uncaught target signal 6 (Aborted) - core dumped

</details>

Wasmtime GitHub notifications bot (Jun 03 2020 at 21:10):

plicease commented on Issue #1716:

might be related #1774?

Wasmtime GitHub notifications bot (Jun 03 2020 at 21:16):

cfallin commented on Issue #1716:

Hi, sorry, I missed this issue previously; #1774 (which I just merged) should fix this. I don't have your precise test-case handy; please let us know if it still fails and I can investigate further!

Wasmtime GitHub notifications bot (Jun 03 2020 at 22:11):

plicease commented on Issue #1716:

:tada: works thanks!

Wasmtime GitHub notifications bot (Jun 03 2020 at 22:11):

plicease closed Issue #1716:

• What are the steps to reproduce the issue?

1. Adjust the multi.c example that comes with wasmtime #1715
2. compile and run on aarch64

pi1% env RUST_BACKTRACE=1 ./a.out
Initializing...
Compiling module...
thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: std::panicking::begin_panic
  12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs
  13: cranelift_codegen::machinst::lower::Lower<I>::lower
  14: cranelift_codegen::machinst::compile::compile
  15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function
  16: cranelift_codegen::context::Context::compile
  17: cranelift_codegen::context::Context::compile_and_emit
  18: wasmtime_jit::compiler::make_trampoline
  19: wasmtime_jit::compiler::Compiler::compile
  20: wasmtime_jit::instantiate::CompiledModule::new
  21: wasmtime::module::Module::from_binary_unchecked
  22: wasmtime::module::Module::from_binary
  23: wasmtime_module_new
  24: main
  25: __libc_start_main
  26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 3705270992
Abort (core dumped)

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.

• Which Wasmtime version / commit hash / branch are you using?

This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

Raspberry Pi Ubuntu Focal

pi1% uname -a
Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.

Last updated: Nov 22 2024 at 16:03 UTC