Stream: git-wasmtime

Topic: wasmtime / issue #6269 [C API] Enabling debug info makes ...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 23 2023 at 17:48):

Photosounder opened issue #6269:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 23 2023 at 18:10):

Photosounder edited issue #6269:

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

view this post on Zulip Wasmtime GitHub notifications bot (Apr 23 2023 at 18:36):

bjorn3 commented on issue #6269:

See https://github.com/bytecodealliance/wasmtime/issues/3999

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 04:32):

Photosounder commented on issue #6269:

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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 05:17):

cfallin commented on issue #6269:

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...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 15:00):

alexcrichton commented on issue #6269:

I'm going to close this in favor of https://github.com/bytecodealliance/wasmtime/issues/3999 since it's the same issue as that one, but thanks for the report!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 15:00):

alexcrichton closed issue #6269:

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

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 15:02):

alexcrichton commented on issue #6269:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2023 at 16:13):

Photosounder commented on issue #6269:

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.

Last updated: Dec 23 2024 at 12:05 UTC