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

index out of bounds in crates/cranelift/src/debug/transform/attr.rs #8884

Closed
dicej opened this issue Jun 28, 2024 · 1 comment · Fixed by #8913
Closed

index out of bounds in crates/cranelift/src/debug/transform/attr.rs #8884

dicej opened this issue Jun 28, 2024 · 1 comment · Fixed by #8913
Labels
bug Incorrect behavior in the current implementation that needs fixing

Comments

@dicej
Copy link
Contributor

dicej commented Jun 28, 2024

While working on dotnet/runtimelab#2614, which involved updating the NativeAOT-LLVM build of the .NET runtime to target WASIp2, I tried to debug the System.Net.Http.Functional.Tests assembly using GDB and Wasmtime. The -c Debug build of that assembly worked (i.e. I was able to run it, set breakpoints, get stack traces, etc.), but the -c Release build triggered an assertion failure in the DWARF processing code.

I tried to reproduce this with a simple "hello, world" CLI app, but wasn't able to.

Test Case

System.Net.Http.Functional.Tests.wasm.gz

Steps to Reproduce

  • gunzip System.Net.Http.Functional.Tests.wasm.gz
  • cargo install --git https://github.com/bytecodealliance/wasmtime --rev 9dff778c wasmtime-cli
  • RUST_BACKTRACE=1 wasmtime -S http -D debug-info -O opt-level=0 System.Net.Http.Functional.Tests.wasm

Expected Results

I expected Wasmtime to run the component without crashing.

Actual Results

thread 'main' panicked at crates/cranelift/src/debug/transform/attr.rs:119:59:
index out of bounds: the len is 1 but the index is 2
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_bounds_check
   3: wasmtime_cranelift::debug::transform::attr::clone_die_attributes
   4: wasmtime_cranelift::debug::transform::unit::clone_unit
   5: wasmtime_cranelift::debug::transform::transform_dwarf
   6: wasmtime_cranelift::debug::write_debuginfo::emit_dwarf
   7: <wasmtime_cranelift::compiler::Compiler as wasmtime_environ::compile::Compiler>::append_dwarf
   8: wasmtime::compile::FunctionIndices::link_and_append_code
   9: wasmtime::compile::build_component_artifacts
  10: core::ops::function::FnOnce::call_once
  11: wasmtime_cache::ModuleCacheEntry::get_data_raw
  12: wasmtime::compile::runtime::<impl wasmtime::compile::code_builder::CodeBuilder>::compile_component
  13: wasmtime_cli::common::RunCommon::load_module
  14: wasmtime_cli::commands::run::RunCommand::execute
  15: wasmtime::main

Versions and Environment

Wasmtime version or commit: 9dff778

Operating system: Ubuntu Linux 24.04

Architecture: ARM64 (Mac Mini M2 Pro)

Extra Info

It's possible that the .NET ILC compiler and/or LLVM are generating invalid DWARF, but if that's the case I would expect Wasmtime to report that gracefully rather than panic.

If it's helpful, I can provide instructions for building the attached Wasm file from source.

@dicej dicej added the bug Incorrect behavior in the current implementation that needs fixing label Jun 28, 2024
@SingleAccretion
Copy link
Contributor

SingleAccretion commented Jul 2, 2024

I have seen this failure in the past. This is an LLVM bug - it produces invalid DWARF when inlined functions are in play.

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.

2 participants