Garbage collection WASM trap

[asteurer]

I've created a reproduction of the trap error here: https://github.com/asteurer/gc-trap-repro

Overview

When a long-lived Go component calls an import function that returns heap-allocated data often enough, this will trigger Go's garbage collector which then causes the component to trap with the following error:

Error: error while executing at wasm backtrace:
    0: 0x26bf0e - <unknown>!clock_time_get
    1: 0x26fecf - <unknown>!<wasm function 4>
    2:  0x8d661 - <unknown>!runtime.clock_time_get
    3:  0x8edf6 - <unknown>!runtime.nanotime1
    4:  0x54a4e - <unknown>!runtime.gcAssistAlloc1
    5:  0x54720 - <unknown>!runtime.gcAssistAlloc.func2
    6: 0x11ab50 - <unknown>!runtime.systemstack
    7:  0x53fed - <unknown>!runtime.gcAssistAlloc
    8:  0x2daee - <unknown>!runtime.deductAssistCredit
    9: 0x10e169 - <unknown>!runtime.mallocgc
   10: 0x115d30 - <unknown>!runtime.growslice
   11:  0x95cdf - <unknown>!runtime.__Pinner_.Pin
   12: 0x17b0b0 - <unknown>!go.bytecodealliance.org_pkg_wit_runtime.Allocate
   13: 0x17b884 - <unknown>!go.bytecodealliance.org_pkg_wit_runtime.cabiRealloc
   14: 0x17b9dd - <unknown>!cabi_realloc
   15: 0x26ff59 - <unknown>!<wasm function 15>
   16: 0x17ba0c - <unknown>!wit_component_wit_world.wasm_import_get_str
   17: 0x17bb78 - <unknown>!wit_component_wit_world.GetStr
   18: 0x17be64 - <unknown>!wit_component_export_wit_world.Run
   19: 0x17c065 - <unknown>!main.wasm_export_wit_world_run

Caused by:
    wasm trap: cannot leave component instance

Identified Workaround

The current workaround is to call runtime.GC() in the relevant export function(s)

@dicej

[dicej]

Oof, yeah the rule is that cabi_realloc may not call any imported functions, and from the stack trace we see it's trying to call an import to get the current time. I don't know offhand why it would need to do that to perform a GC, but I'll investigate when I get the chance and see if there's a workaround (e.g. set/reset a global variable when entering/exiting cabi_realloc and use that to determine whether to return a fake time instead of calling the import).

[asteurer]

Appreciate it! Excited to hear what you find out.

[dicej]

OK, I just finally got around to looking at this. As I suspected this code is measuring the time spent doing a GC "assist" operation and later using that measurement to control CPU usage in mgclimit.go. I don't know enough about that code to foresee the implications of lying to it (i.e. returning a fake time value when called from a cabi_realloc invocation), but I'm guessing it's better than trapping.

I'll try running the reproduction case you provided with a modified wasi_snapshot_preview1 adapter that always returns zero as the current time and see if that fixes it. That won't be the actual solution, but trying it should tell us whether there are any other issues besides that, and hopefully point us to a proper solution.

[dicej]

Indeed, if I build with a modified wasi_snapshot_preview1 adapter that always returns the same value for clock_time_get instead of calling the WASIp2 import, the test case runs fine (i.e. prints Hello! over and over indefinitely).

[dicej]

This is partly addressed by bytecodealliance/wasmtime#13563 and bytecodealliance/go-pkg#7. I can't easily update wit-bindgen-go or componentize-go to use those changes yet because wit-bindgen-go's tests use wasi-preview1-component-adapter-provider which can't be used as a Git dependency because it has a non-standard build process that involves a pre-processed Cargo.toml template. So I think we'll need to wait for Wasmtime 46.0.0 to be released later this month to finish addressing this.

[dicej]

Meanwhile, @asteurer would you be up for converting your test repo to a test we can add to this project, e.g. running the loop a finite but generous number of times and verifying that it doesn't trap?

[asteurer]

TODO once Wasmtime 46.0.0 releases:

• Cut a new release of go-pkg
• Update wit-bindgen-go to use the new go-pkg release
• Create a PR that includes both an updated p1 -> p2 adapter and a new test for this bug.
• Cut a new componentize-go release