[C API] Enabling debug info makes wasmtime_module_new() crash

[Photosounder]

I wrote a host to run functions from WASM reactors and with one WASM module after calling one of its functions I get the following trap message:

error while executing at wasm backtrace:
    0: 0xeb40 - <unknown>!<wasm function 80>
    1: 0x1dba3 - <unknown>!<wasm function 130>
    2:  0x87d - <unknown>!<wasm function 7>

It's rather unhelpful so I wanted to add debug information, which I thought I'd do by adding wasmtime_config_debug_info_set(config, true); to my code. But now that I've done this when my program runs wasmtime_module_new() I get this:

thread '<unnamed>' panicked at 'assertion failed: range_start < range_end', crates\cranelift\src\debug\transform\expression.rs:689:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/001a77fac33f6560ff361ff38f661ff5f1c6bf85/library\std\src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/001a77fac33f6560ff361ff38f661ff5f1c6bf85/library\core\src/panicking.rs:64:14
   2: core::panicking::panic
             at /rustc/001a77fac33f6560ff361ff38f661ff5f1c6bf85/library\core\src/panicking.rs:114:5
   3: wasmtime_cranelift::debug::transform::expression::ValueLabelRangesBuilder::process_label
   4: wasmtime_cranelift::debug::transform::expression::CompiledExpression::build_with_locals
   5: wasmtime_cranelift::debug::transform::simulate::generate_simulated_dwarf
   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>::append_dwarf
   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_new
  14: wasm_host
             at .\C:/msys/home/exp/wasm_app/Wasmtime host/wasm_host.c:217:11
  15: rl_sdl_standard_main_loop
             at .\D:/VC_libs/include/rouziclib/libraries/sdl.c:998:3
  16: main_loop
             at .\C:/msys/home/exp/wasm_app/Wasmtime host/wasm_host.c:318:2

I have no idea why. I compiled the WASM module (from C using wasi-sdk) with -Og -g3, which I'm not sure is sufficient to get the debug info needed. Here's the host program's relevant code:

	// WASM initialisation
	wasm_config_t *config = wasm_config_new();
	wasmtime_config_debug_info_set(config, true);
	ctx.engine = wasm_engine_new_with_config(config);
	ctx.store = wasmtime_store_new(ctx.engine, NULL, NULL);
	ctx.context = wasmtime_store_context(ctx.store);

	// Create a linker with WASI functions defined
	ctx.linker = wasmtime_linker_new(ctx.engine);
	error = wasmtime_linker_define_wasi(ctx.linker);

	// Load WASM file
	buffer_t wasm_buf = buf_load_raw_file(path);

	// Compile WASM
	error = wasmtime_module_new(ctx.engine, wasm_buf.buf, wasm_buf.len, &ctx.module);

The version of Wasmtime is the dev build wasmtime-dev-x86_64-mingw-c-api.zip from the Releases from 7 hours ago.

Edit: I just checked with a .wasm module that works fine and when I enable debug info it also works fine, just not with a buggy WASM module. So it would probably help to include the fault module:
test.zip

[bjorn3]

See #3999

[Photosounder]

I see, doesn't seem like I should hold my breath for a fix. So in a situation like the one described at the beginning of my post, how does one go about locating the source of the problem?

[cfallin]

The state-of-the-art is unfortunately "printf debugging" in cases like this. The situation described here is unfortunately still the case -- we don't have anyone who understands the existing DWARF-handling code deeply enough to attempt to fix it -- but we do at least have some discussions going in our "debugging SIG" that might eventually lead to something. The bottleneck as always is engineer time...

[alexcrichton]

I'm going to close this in favor of #3999 since it's the same issue as that one, but thanks for the report!

[alexcrichton]

I will mention though that as for your original issue you can try enabling debug information in whatever is compiled to wasm. That will generate a filename/line number in the trap backtrace which can be useful for debugging.

[Photosounder]

Thanks, I realised that I had stripping enabled in my module compilation command. Anyway my problem was due to the module's stack size being way too small (2048 bytes), it's a shame the runtime didn't warn about this.