Panic during component instantiation

[moldhouse]

Test Case

Work in progress. Currently we only witness this in our production code base. We are currently working on a minimal example. Yet we found it may be valuable to share the back trace with you up front.

Steps to Reproduce

See above.

Expected Results

Instantiating the component without a panic.

Actual Results

We encounter a panic.

thread 'tokio-runtime-worker' panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustix-1.0.5/src/backend/linux_raw/param/auxv.rs:302:68:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: core::option::unwrap_failed
   4: rustix::backend::param::auxv::init_auxv_impl
   5: rustix::backend::param::auxv::init_auxv
   6: <wasmtime::runtime::vm::instance::allocator::on_demand::OnDemandInstanceAllocator as wasmtime::runtime::vm::instance::allocator::InstanceAllocatorImpl>::allocate_fiber_stack
   7: wasmtime::runtime::component::instance::InstancePre<T>::instantiate_async::{{closure}}
   8: pharia_kernel::skills::v0_3::skill::SkillPre<_T>::instantiate_async::{{closure}}
   9: <pharia_kernel::skills::v0_3::skill::SkillPre<engine_room::LinkerImpl<alloc::boxed::Box<dyn pharia_kernel::csi::CsiForSkills+core::marker::Send>>> as pharia_kernel::skills::Skill>::run_as_function::{{closure}}
  10: pharia_kernel::skill_runtime::SkillRuntimeActor<C,S>::run::{{closure}}::{{closure}}
  11: <futures_util::stream::stream::select_next_some::SelectNextSome<St> as core::future::future::Future>::poll
  12: tokio::runtime::task::core::Core<T,S>::poll
  13: tokio::runtime::task::raw::poll
  14: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  15: tokio::runtime::task::raw::poll

Versions and Environment

We see the panic in wasmtime 32, not in 31. We do not see the problem on all platforms.

We saw it on:

• MacOS (arm) running a Container with Ubuntu 24 (always)
• GitHub CI running the same Container (sometimes, flaky)

We did not see it on:

• MacOS (arm) without Container
• Running the Container in our Prod environment

[moldhouse]

@pacman82 @markus-klein-aa

[bjorn3]

The error happens at https://github.com/bytecodealliance/rustix/blob/cb01fbe4660844b67fdd4eee2a5f769518f6a655/src/backend/linux_raw/param/auxv.rs#L302 which indicates that one of the auxv entries for the process may be incorrect. By the way are you running an arm64 version of Wasmtime or an x86_64 version on your mac?

On CI we build for x86_64. Locally on our Mac OS Developer machines we build with:

podman build . --tag pharia-kernel --platform linux/arm64

I am walking back a bit, that we witness the same error on CI. We need to validate that. It might be a different issue.

Verified it also fails locally on our dev machines if we build for x86_64.

Yet, it does not fail, if we build it natively without a container around it.

[alexcrichton]

I'm not sure why this is panicking as I'm not familiar with auxv or how rustix is calculating the host page size, but I've submitted #10803 to remove calls to this function which will somewhat indirectly "fix" this insofar as Wasmtime won't panic at that location any more.

@markus-klein-aa if you're able to reduce I believe the rustix project would likely be thankful to have an issue about this panic on their issue tracker.

Yeah, absolutely we want a minimal example. Yet this is some effort and we thought there might be value in sharing the stack trace up front.

[alexcrichton]

FWIW the reproduction will likely be invoking this function and that's pretty much it. The main thing to reproduce is your environment which triggers this panic.

Hey, thanks for the hint. I'll give it a try!