Stream: git-wasmtime

Topic: wasmtime / issue #11830 "Couldn't materialize" any expres...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2025 at 13:21):

edward-playbit opened issue #11830:

Test Case

Compile the following two .c files with these commands on macOS:

clang -c --target=wasm32 -o a.o a.c -g
wasm-ld -o a.wasm a.o --import-memory --no-entry --export=func
clang -o b b.c -Wall -Wextra -fsanitize=address -g \
    -I wasmtime-37.0.1.2/include -L wasmtime-37.0.1.2/lib -l wasmtime

a.c:

void func() {
    int s = 0;
    for (int i = 0; i < 5; i++) {
        s += i;
    }
}

b.c:

#include <stdio.h>
#include <assert.h>
#include <wasm.h>
#include <wasmtime.h>

int main() {
    wasm_trap_t* trap = NULL;
    wasmtime_error_t* err = NULL;

    wasm_config_t* config = wasm_config_new();
    wasmtime_config_debug_info_set(config, true);
    wasmtime_config_cranelift_opt_level_set(config, WASMTIME_OPT_LEVEL_NONE);

    wasm_engine_t* engine = wasm_engine_new_with_config(config);
    wasmtime_store_t* store = wasmtime_store_new(engine, NULL, NULL);
    wasmtime_context_t* cx = wasmtime_store_context(store);
    wasmtime_linker_t* linker = wasmtime_linker_new(engine);
    wasm_limits_t limits = { .min = 256, .max = UINT32_MAX };
    wasm_memorytype_t* mem_ty = wasm_memorytype_new(&limits);
    wasmtime_memory_t  memory;

    err = wasmtime_memory_new(cx, mem_ty, &memory);
    assert(!err);
    wasm_memorytype_delete(mem_ty);
    wasmtime_extern_t mem_extern = {
        .kind = WASMTIME_EXTERN_MEMORY,
        .of = {
          .memory = memory,
        },
    };
    err = wasmtime_linker_define(linker, cx, "env", 3, "memory", 6, &mem_extern);
    assert(!err);

    FILE* f = fopen("a.wasm", "rb");
    assert(f);
    fseek(f, 0, SEEK_END);
    size_t n = ftell(f);
    fseek(f, 0, SEEK_SET);
    wasm_byte_vec_t bytes;
    wasm_byte_vec_new_uninitialized(&bytes, n);
    fread(bytes.data, n, 1, f);
    fclose(f);

    wasmtime_module_t* module = NULL;
    err = wasmtime_module_new(engine, (uint8_t*)bytes.data, bytes.size, &module);
    assert(!err);
    wasm_byte_vec_delete(&bytes);
    wasmtime_instance_t instance = {};
    err = wasmtime_linker_instantiate(linker, cx, module, &instance, &trap);
    assert(!err);

    wasmtime_extern_t item = {};
    bool success = wasmtime_instance_export_get(cx, &instance, "func", 4, &item);
    assert(success);
    assert(item.kind == WASMTIME_EXTERN_FUNC);
    err = wasmtime_func_call(cx, &item.of.func, NULL, 0, NULL, 0, &trap);
    assert(!err);

    return 0;
}

Steps to Reproduce

Run the compiled executable under LLDB with the following command:

lldb b -b -o "b func" -o "r" -o "n" -o "n" -o "p s"

Note: You will need to create the file ~/.lldbinit with the following contents if not already:

settings set plugin.jit-loader.gdb.enable on

Expected Results

To see the current value of the s variable printed, i.e. 0.

Actual Results

Instead, the following error message is displayed:

error: Couldn't materialize: couldn't get the value of variable s: variable not available
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

Versions and Environment

Wasmtime version or commit: 37.0.1.2

clang, wasm-ld and lldb version: 21.1.2 (from Homebrew)

Operating system: macOS 15.6.1 (24G90)

Architecture: Apple M2 Max (aarch64)

Extra Info

There is an existing issue with something similar: https://github.com/bytecodealliance/wasmtime/issues/11337. However that issue is only in the case "after indirect call", while this issue is that variables cannot be displayed at all.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2025 at 13:21):

edward-playbit added the bug label to Issue #11830.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2025 at 14:41):

alexcrichton added the wasmtime:debugging label to Issue #11830.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2025 at 16:49):

cfallin commented on issue #11830:

@edward-playbit I'll make the same comment I made in #11337 (because "after indirect call" does not alter the fundamental underlying case):

Unfortunately I don't have an easy answer/fix, but I'll note that historically our native-debugger support has been quite best-effort, and is more or less unmaintained at the moment. The DWARF translation has had known bugs, and we know that various aspects of our lowering can cause values to become unavailable. All of that to say: I'm not surprised that you are finding holes, and I wouldn't recommend relying on debugging by attaching a native debugger to wasmtime at the moment.

We do have a debugging RFC that captures a lot of thinking about our debugging plans from a year ago; and assuming plans don't change, I should be able to start work on pieces of this later in the year.

My update on that since that Jul 28 comment is that I am now actively working on "guest debugging", which will subsume use of a native debugger as you're attempting here.


Last updated: Dec 06 2025 at 06:05 UTC