Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasmtime panic with .NET 9.0 WASI wasm file #8904

Closed
CryZe opened this issue Jul 5, 2024 · 0 comments · Fixed by #8913
Closed

wasmtime panic with .NET 9.0 WASI wasm file #8904

CryZe opened this issue Jul 5, 2024 · 0 comments · Fixed by #8913
Labels
bug Incorrect behavior in the current implementation that needs fixing

Comments

@CryZe
Copy link
Contributor

CryZe commented Jul 5, 2024

Test Case

net9_debug_crash.zip

Steps to Reproduce

Configure the engine the following way:

let mut engine_config = wasmtime::Config::new();

engine_config
    .cranelift_opt_level(OptLevel::Speed)
    .debug_info(true)
    .wasm_backtrace_details(WasmBacktraceDetails::Enable)
    .epoch_interruption(true);
    
let engine = Engine::new(&engine_config).unwrap();

Module::from_binary(&engine, module).unwrap();

Expected Results

It compiles the module.

Actual Results

It panics:

thread 'main' panicked at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\debug\transform\attr.rs:119:59:
index out of bounds: the len is 1 but the index is 1
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
   1: core::panicking::panic_fmt
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
   2: core::panicking::panic_bounds_check
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:275
   3: wasmtime_cranelift::debug::transform::attr::clone_die_attributes<gimli::read::endian_slice::EndianSlice<gimli::endianity::LittleEndian> >
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\debug\transform\attr.rs:119
   4: wasmtime_cranelift::debug::transform::unit::clone_unit<gimli::read::endian_slice::EndianSlice<gimli::endianity::LittleEndian> >
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\debug\transform\unit.rs:478
   5: wasmtime_cranelift::debug::transform::transform_dwarf
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\debug\transform\mod.rs:200
   6: wasmtime_cranelift::debug::write_debuginfo::emit_dwarf
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\debug\write_debuginfo.rs:185
   7: wasmtime_cranelift::compiler::impl$3::append_dwarf
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-cranelift-22.0.0\src\compiler.rs:487
   8: wasmtime::compile::FunctionIndices::link_and_append_code
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-22.0.0\src\compile.rs:740   
   9: wasmtime::compile::build_artifacts<wasmtime::compile::runtime::MmapVecWrapper>
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-22.0.0\src\compile.rs:100   
  10: wasmtime::compile::code_builder::CodeBuilder::compile_cached<tuple$<wasmtime_environ::module_artifacts::CompiledModuleInfo,wasmtime_environ::module_types::ModuleTypes> >
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-22.0.0\src\compile\runtime.rs:64
  11: wasmtime::compile::code_builder::CodeBuilder::compile_module
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-22.0.0\src\compile\runtime.rs:82
  12: wasmtime::runtime::module::Module::from_binary
             at C:\Users\cryze\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-22.0.0\src\runtime\module.rs:323

Versions and Environment

Wasmtime version or commit: 22.0.0

Operating system: Windows 11

Architecture: x86_64

@CryZe CryZe added the bug Incorrect behavior in the current implementation that needs fixing label Jul 5, 2024
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jul 8, 2024
I'm not entirely sure what causes this but Wasmtime shouldn't panic with
invalid DWARF. In general (bytecodealliance#5537) Wasmtime's support for DWARF needs to
be rewritten, but in the meantime let's play whack-a-mole with panics
and try to paper over issues.

Closes bytecodealliance#8884
Closes bytecodealliance#8904
github-merge-queue bot pushed a commit that referenced this issue Jul 8, 2024
I'm not entirely sure what causes this but Wasmtime shouldn't panic with
invalid DWARF. In general (#5537) Wasmtime's support for DWARF needs to
be rewritten, but in the meantime let's play whack-a-mole with panics
and try to paper over issues.

Closes #8884
Closes #8904
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jul 9, 2024
I'm not entirely sure what causes this but Wasmtime shouldn't panic with
invalid DWARF. In general (bytecodealliance#5537) Wasmtime's support for DWARF needs to
be rewritten, but in the meantime let's play whack-a-mole with panics
and try to paper over issues.

Closes bytecodealliance#8884
Closes bytecodealliance#8904
fitzgen added a commit that referenced this issue Jul 9, 2024
* Add custom-pages-sizes to CLI flags (#8917)

* Update dependency on `wit-bindgen` (#8911)

* Update dependency on `wit-bindgen`

Updating to the latest released version.

* Add vets

* Fix build of test-programs

* Fix panic with invalid DWARF file indices (#8913)

I'm not entirely sure what causes this but Wasmtime shouldn't panic with
invalid DWARF. In general (#5537) Wasmtime's support for DWARF needs to
be rewritten, but in the meantime let's play whack-a-mole with panics
and try to paper over issues.

Closes #8884
Closes #8904

* Wasmtime: Pop GC LIFO roots even when there is no GC heap (#8899)

* Wasmtime: Pop GC LIFO roots even when there is no GC heap

We can create and root `i31ref`s without ever allocating a GC heap for the
store, so we can't guard popping LIFO roots on the presence of a GC heap or else
we risk unbounded growth of the LIFO root set.

* Fix build with the gc feature disabled

---------

Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior in the current implementation that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant