Stream: git-wasmtime

Topic: wasmtime / issue #11846 C API breakpoint triggering appea...

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

adv-sw opened issue #11846:

Test Case

Repro: http://advance-software.com/misc/test_breakpoint.zip)

Steps to Reproduce - Windows

  1. Build your wasmtime.exe & put it in repro dist subdirectory.
    (there's a 0 length placeholder there right now)

  2. Then [command line] :

    lldb -- .\wasmtime.exe -D debug-info --invoke app_init .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    & that works (for me)

  3. Build the c-api test in host, using visual studio 2022 - a couple of hardwired paths in there to change but its mostly portable. resulting .exe should end up in repro "dist" subdir, overwriting the 0 length placeholder.

  4. Verify it works (from dist) :

    .\test_wasmtime_debug_api.exe .\breakable.wasm
    Should get result : 42

  5. Next, run under lldb :

    lldb -- .\test_wasmtime_debug_api.exe .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    breakpoint not hit.

that's the bug.

What do you expect to happen?

breakpoint should be hit when running breakable.wasm from both wasmtime & c API test.

What actually happens?

breakpoint hit when running breakable.wasm from wasmtime, not hit from c API test.

Versions and Environment

wasmtime trunk

lldb version 20.1.7

Wasmtime version or commit: TODO

Operating system: windows 11 - latest.

Architecture: x64-84

Extra Info

Source to breakable.wasm is in wasm subdir - its trivial.

Tried c-api buiit static & dynamic. static my preference as less sensitive to where .dll's are on Windows which has caused system to be unreliable in the past. Neither works.

Difference (guess) : wasmtime likely uses wasmtime API, the C API test uses the wasm API.

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

adv-sw added the bug label to Issue #11846.

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

adv-sw edited issue #11846:

Test Case

Repro: http://advance-software.com/misc/test_breakpoint.zip)

Steps to Reproduce - Windows

  1. Build your wasmtime.exe & put it in repro dist subdirectory.
    (there's a 0 length placeholder there right now)

  2. Then [command line] :

    lldb -- .\wasmtime.exe -D debug-info --invoke app_init .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    & that works (for me)

  3. Build the c-api test in host, using visual studio 2022 - a couple of hardwired paths in there to change but its mostly portable. resulting .exe should end up in repro "dist" subdir, overwriting the 0 length placeholder.

  4. Verify it works (from dist) :

    .\test_wasmtime_debug_api.exe .\breakable.wasm
    Should get result : 42

  5. Next, run under lldb :

    lldb -- .\test_wasmtime_debug_api.exe .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    breakpoint not hit.

that's the bug.

What do you expect to happen?

breakpoint should be hit when running breakable.wasm from both wasmtime & c API test.

What actually happens?

breakpoint hit when running breakable.wasm from wasmtime, not hit from c API test.

Versions and Environment

lldb version 20.1.7

Wasmtime version or commit: trunk

Operating system: windows 11 - latest.

Architecture: x64-84

Extra Info

Source to breakable.wasm is in wasm subdir - its trivial.

Tried c-api buiit static & dynamic. static my preference as less sensitive to where .dll's are on Windows which has caused system to be unreliable in the past. Neither works.

Difference (guess) : wasmtime likely uses wasmtime API, the C API test uses the wasm API.

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

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

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

adv-sw closed issue #11846:

Test Case

Repro: http://advance-software.com/misc/test_breakpoint.zip)

Steps to Reproduce - Windows

  1. Build your wasmtime.exe & put it in repro dist subdirectory.
    (there's a 0 length placeholder there right now)

  2. Then [command line] :

    lldb -- .\wasmtime.exe -D debug-info --invoke app_init .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    & that works (for me)

  3. Build the c-api test in host, using visual studio 2022 - a couple of hardwired paths in there to change but its mostly portable. resulting .exe should end up in repro "dist" subdir, overwriting the 0 length placeholder.

  4. Verify it works (from dist) :

    .\test_wasmtime_debug_api.exe .\breakable.wasm
    Should get result : 42

  5. Next, run under lldb :

    lldb -- .\test_wasmtime_debug_api.exe .\breakable.wasm
    (lldb) b app_init
    (lldb) r
    breakpoint not hit.

that's the bug.

What do you expect to happen?

breakpoint should be hit when running breakable.wasm from both wasmtime & c API test.

What actually happens?

breakpoint hit when running breakable.wasm from wasmtime, not hit from c API test.

Versions and Environment

lldb version 20.1.7

Wasmtime version or commit: trunk

Operating system: windows 11 - latest.

Architecture: x64-84

Extra Info

Source to breakable.wasm is in wasm subdir - its trivial.

Tried c-api buiit static & dynamic. static my preference as less sensitive to where .dll's are on Windows which has caused system to be unreliable in the past. Neither works.

Difference (guess) : wasmtime likely uses wasmtime API, the C API test uses the wasm API.

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

adv-sw commented on issue #11846:

Fixed. Cause was missing conf.h

Fixed by manually recreating from conf.h.in with all current options enabled.

https://github.com/bytecodealliance/wasmtime/issues/11849

Last updated: Dec 06 2025 at 06:05 UTC