wasmtime run -g fails with 'assertion failed: (left < right)

[tiran]

wasmtime panics and fails for me every time I try to run Python's WASI builds with wasmtime run -g (Generate debug information).

Test Case

Python-3.11.0rc1-wasm32-wasi-16.zip

Steps to Reproduce

wasmtime run -g --dir . -- python.wasm -c pass

Expected Results

I'm able to execute Python 3.11 WASI build with DWARF debug symbols.

Actual Results

$ RUST_BACKTRACE=1 wasmtime run -g --dir . -- python.wasm -c pass
thread 'main' panicked at 'assertion failed: `(left < right)`
  left: `817`,
 right: `816`', crates/cranelift/src/debug/transform/expression.rs:690:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
   2: wasmtime_cranelift::debug::transform::expression::ValueLabelRangesBuilder::process_label
   3: wasmtime_cranelift::debug::transform::expression::CompiledExpression::build_with_locals
   4: wasmtime_cranelift::debug::transform::attr::clone_die_attributes
   5: wasmtime_cranelift::debug::transform::unit::clone_unit
   6: wasmtime_cranelift::debug::transform::transform_dwarf
   7: wasmtime_cranelift::debug::write_debuginfo::emit_dwarf
   8: <wasmtime_cranelift::compiler::Compiler as wasmtime_environ::compilation::Compiler>::emit_obj
   9: wasmtime::module::Module::build_artifacts
  10: core::ops::function::FnOnce::call_once
  11: wasmtime_cache::ModuleCacheEntry::get_data_raw
  12: wasmtime::module::Module::from_binary
  13: wasmtime::module::Module::from_file
  14: wasmtime_cli::commands::run::RunCommand::load_module
  15: wasmtime_cli::commands::run::RunCommand::execute
  16: wasmtime::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Versions and Environment

Wasmtime version or commit: 0.39.1

Operating system: Fedora

Architecture: x86_64

WASI-SDK: 16.0

Extra Info

Anything else you'd like to add?

[cfallin]

@tiran thanks for the report!

We currently don't have anyone on the project who understands our DWARF-handling code well and has time to work on it; so while this is definitely a bug, it's not likely to have a fast resolution. We do have an intent to have someone eventually focus on this, as priorities allow, so we should keep this issue open. Just wanted to give some context on the current situation...

[alexcrichton]

Closing as a duplicate of #3999