Stream: git-wasmtime

Topic: wasmtime / issue #8884 index out of bounds in crates/cran...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2024 at 14:25):

dicej added the bug label to Issue #8884.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2024 at 14:25):

dicej opened issue #8884:

While working on https://github.com/dotnet/runtimelab/pull/2614, which involved updating the NativeAOT-LLVM target in 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

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: 9dff778c

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2024 at 14:28):

dicej edited issue #8884:

While working on https://github.com/dotnet/runtimelab/pull/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

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: 9dff778c

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 02 2024 at 11:19):

SingleAccretion commented on issue #8884:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jul 02 2024 at 11:19):

SingleAccretion edited a comment on issue #8884:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jul 02 2024 at 13:06):

SingleAccretion edited a comment on issue #8884:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jul 08 2024 at 18:11):

alexcrichton closed issue #8884:

While working on https://github.com/dotnet/runtimelab/pull/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

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: 9dff778c

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.

Last updated: Dec 23 2024 at 12:05 UTC