Stream: git-wasmtime

Topic: wasmtime / issue #5032 Implement the WebAssembly GC Proposal


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

Srinivasa314 opened issue #5032:

Feature

Implement the WebAssembly GC proposal

Benefit

Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach

Implementation

Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted

view this post on Zulip Wasmtime GitHub notifications bot (Feb 27 2023 at 06:56):

sdeleuze commented on issue #5032:

FYI we are now able to run a Kotlin/Wasm HTTP server via KoWasm on Node.js and I would be happy to leverage Wasmtime to run it as soon as it will get GC support.

This would be a really good fit since we would like to leverage WASI Preview2+ and Wasm Component Model asap.

See also my blog post The huge potential of Kotlin/Wasm for more context.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 20:33):

fitzgen commented on issue #5032:

Heads up: I am working on an RFC to work out the design of our Wasm GC support. I expect to start implementing Wasm GC once that RFC reaches consensus and merges and I've finished implementing Wasm tail calls.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 20:33):

fitzgen assigned issue #5032 (assigned to fitzgen):

Feature

Implement the WebAssembly GC proposal

Benefit

Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach

Implementation

Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted

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

fitzgen commented on issue #5032:

RFC is up: https://github.com/bytecodealliance/rfcs/pull/31

view this post on Zulip Wasmtime GitHub notifications bot (Oct 24 2023 at 08:29):

tw-atroehrsm commented on issue #5032:

hey there! any updates on this front? Really looking forward to use Kotlin/WASM with this runtime.
For now only V8 is feasible, as it includes a GC and has implemented the proposal

view this post on Zulip Wasmtime GitHub notifications bot (Oct 25 2023 at 16:57):

fitzgen commented on issue #5032:

There is work on parsing and validation, and refactors setting the stage for these things, happening in the wasm-tools repository, since we need to be able to parse and validate Wasm before we can compile and run it.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 12:40):

smndtrl commented on issue #5032:

@fitzgen could you provide links to the issues over there? I want to keep track with the progress due to the impact on Kotlin

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 17:09):

fitzgen commented on issue #5032:

@smndtrl since https://github.com/bytecodealliance/wasm-tools/pull/1346 merged, all GC spec tests are passing in wasm-tools.

You can look at https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#incremental-implementation-plan and https://docs.wasmtime.dev/contributing-implementing-wasm-proposals.html to get an idea of what is still to be done.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 10:11):

tw-atroehrsm commented on issue #5032:

So it there any timeline, roadmap when this will be available at least with the null GC?

this was merged in may 2023 so can be marked as done?

what could one do to support this effort?

![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288 is merged since May

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 10:13):

tw-atroehrsm edited a comment on issue #5032:

So it there any timeline, roadmap when this will be available at least with the null GC?

this was merged in may 2023 so can be marked as done?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288

what could one do to support this effort?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 10:13):

tw-atroehrsm edited a comment on issue #5032:

So it there any timeline, roadmap when this will be available at least with the null GC?

this was merged in may 2023 so can be marked as done?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288

what could one do to support this effort?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 10:13):

tw-atroehrsm edited a comment on issue #5032:

So it there any timeline, roadmap when this will be available at least with the null GC?

this was merged in may 2023 so can be marked as done?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)

https://github.com/bytecodealliance/wasmtime/pull/5288

what could one do to support this effort?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 17:47):

fitzgen commented on issue #5032:

The function references proposal still needs to be exposed in the embedder API.

I am actively working on that and the rest of getting Wasm GC implemented. Right now it mostly involves some refactoring to the runtime's internals to pave the way for future changes. Unfortunately, there isn't much that can be split out and implemented in parallel right now.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 15 2024 at 00:33):

fitzgen commented on issue #5032:

FYI: https://github.com/bytecodealliance/wasmtime/pull/7943 finishes the function references proposal and takes the first baby steps towards Wasm GC inside Wasmtime, adding support for Wasm GC's nofunc and a Config::wasm_gc(enabled) knob.

view this post on Zulip Wasmtime GitHub notifications bot (May 26 2024 at 17:10):

oovm commented on issue #5032:

It looks like all gc types declarations are supported.

Can we create an issue to track the progress of the gc proposal, such as

view this post on Zulip Wasmtime GitHub notifications bot (May 29 2024 at 00:45):

fitzgen commented on issue #5032:

Yes all the types are supported now, but instantiating them is not implemented yet; I'm working on it. Then the various instructions. Then the collector itself. (Right now we are reusing the deferred reference-counting collector that Wasmtime already has, so we can collect some garbage, but not cycles).

Personally, I'm not a huge fan of opening a bunch of tracking issues for things already effectively tracked by this issue. Happy to cross-link more PRs here as they come in though.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2024 at 10:02):

lppedd commented on issue #5032:

Hi there! Just wondering if there are noteworthy updates on this front.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2024 at 16:09):

fitzgen commented on issue #5032:

All the struct-related instructions are implemented.

Almost done with array-related instructions.

Still to do:

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

fitzgen commented on issue #5032:

Two notes:

  1. All array instructions other than array.{copy,init_elem} have been implemented. Those last two will be coming very soon.

  2. Folks following this issue might also be interested in following https://github.com/bytecodealliance/wasmtime/issues/9351

view this post on Zulip Wasmtime GitHub notifications bot (Oct 01 2024 at 19:11):

bashor commented on issue #5032:

@fitzgen Great news! Thanks for the updates!

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

bashor commented on issue #5032:

@fitzgen, do I understand correctly that storing a funcref in a struct's field is not supported yet?

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:02):

fitzgen commented on issue #5032:

That was true before a few days ago. Now, funcrefs inside GC objects should be fully supported.

And FWIW, all Wasm GC spec tests are now passing on main!

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:02):

fitzgen edited issue #5032:

Feature

Implement the WebAssembly GC proposal

Benefit

Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach

Implementation

Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:03):

fitzgen edited issue #5032:

Feature

Implement the WebAssembly GC proposal

Benefit

Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach

Implementation

Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:04):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:04):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:06):

bashor commented on issue #5032:

@fitzgen, but I got the following error on dev build from f59cad10572b9618b300af9e8fecf2ce13dba373

thread 'main' panicked at crates/wasmtime/src/runtime/vm/gc/enabled/structref.rs:331:17:
not yet implemented: funcrefs in GC objects
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: wasmtime::runtime::vm::gc::enabled::structref::VMStructRef::initialize_field
   3: wasmtime::runtime::gc::enabled::structref::StructRef::_new
   4: wasmtime::runtime::vm::const_expr::ConstEvalContext::struct_new
   5: wasmtime::runtime::vm::const_expr::ConstExprEvaluator::eval
   6: wasmtime::runtime::vm::instance::allocator::initialize_instance
   7: wasmtime::runtime::instance::Instance::new_raw
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
zsh: abort      RUST_BACKTRACE=1 ./wasmtime -W function-references=y -W gc=y

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:08):

fitzgen commented on issue #5032:

@bashor ah! looks like I missed a spot, thanks for finding it. FWIW, I think this should only be reachable from const expressions and host APIs. Will whip up a fix in a minute.

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

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2024 at 23:50):

fitzgen commented on issue #5032:

@bashor fix is over in https://github.com/bytecodealliance/wasmtime/pull/9454 !

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:06):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:07):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:57):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 00:59):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 13:06):

bashor commented on issue #5032:

@fitzgen Thanks!

Now it works! :rocket: https://x.com/bashorov/status/1844725893752553957

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 15:22):

fitzgen commented on issue #5032:

@bashor awesome!! Thanks for kicking the tires :)

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 15:41):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 15:42):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 15:42):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 15:42):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 11 2024 at 19:04):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

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

hoangpq commented on issue #5032:

Hi @bashor

I'm interested in running Kotlin WASI on Wasmtime, so I gave it a try, but I encountered an error. Do you have any ideas

RUST_BACKTRACE=1 ./target/debug/wasmtime -W function-references,gc ./kotlin-wasm-wasi-example-wasm-wasi.wasm
Error: failed to parse WebAssembly module

Caused by:
    exceptions proposal not enabled (at offset 0x6750)

Envs:
- Wasmtime: debug build from Wasmtime main branch
- Wasm from https://github.com/Kotlin/kotlin-wasm-wasi-template

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

alexcrichton commented on issue #5032:

@hoangpq you might be interested in this comment perhaps. Wasmtime doesn't yet implement the exception-handling proposal for WebAssembly, so Kotlin won't run until that's implemented.

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

hoangpq commented on issue #5032:

Thank you @alexcrichton.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2024 at 20:08):

bashor commented on issue #5032:

Hi, @hoangpq!

You can uncomment/add these lines to prevent using EH by Kotlin/Wasm toolchain.

Note that the option was added only to allow earlier experimentation with VMs with limited/lack of EH support. In this mode, throwing an exception will lead to a trap (~program termination).

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2024 at 02:17):

hoangpq commented on issue #5032:

Got it. Thanks, @bashor.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2024 at 18:04):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2024 at 18:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2024 at 18:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2024 at 18:05):

fitzgen edited issue #5032:

Tracking issue for implementation of the WebAssembly GC proposal

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Nov 08 2024 at 14:33):

vouillon commented on issue #5032:

@fitzgen I get the following error:

thread 'main' panicked at crates/wasmtime/src/runtime/values.rs:919:50:
not yet implemented: eqref
stack backtrace:
   0: rust_begin_unwind
             at /build/rustc-1.80-R0vcdR/rustc-1.80-1.80.1+dfsg0ubuntu1/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /build/rustc-1.80-R0vcdR/rustc-1.80-1.80.1+dfsg0ubuntu1/library/core/src/panicking.rs:72:14
   2: wasmtime::runtime::values::Ref::_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:919:50
   3: wasmtime::runtime::values::Val::_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:193:55
   4: wasmtime::runtime::values::Val::ensure_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:213:12
   5: wasmtime::runtime::gc::enabled::arrayref::ArrayRef::_new
             at ./crates/wasmtime/src/runtime/gc/enabled/arrayref.rs:276:9
   6: wasmtime::runtime::vm::const_expr::ConstExprEvaluator::eval
             at ./crates/wasmtime/src/runtime/vm/const_expr.rs:301:33
   7: wasmtime::runtime::vm::instance::allocator::initialize_globals
             at ./crates/wasmtime/src/runtime/vm/instance/allocator.rs:800:13

view this post on Zulip Wasmtime GitHub notifications bot (Nov 08 2024 at 17:21):

fitzgen commented on issue #5032:

@fitzgen I get the following error:

Looks like I missed a spot! Thanks for the report. Can you share the test case and steps to reproduce? Either here or in a new issue is fine. Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 08 2024 at 17:36):

vouillon commented on issue #5032:

I was trying this piece of code: bdd.zip
Using the following command:

./target/debug/wasmtime -W all-proposals=y ./bdd.wasm

view this post on Zulip Wasmtime GitHub notifications bot (Nov 08 2024 at 18:52):

fitzgen commented on issue #5032:

Thanks! I'll take a look soon

view this post on Zulip Wasmtime GitHub notifications bot (Nov 18 2024 at 17:22):

whyoleg commented on issue #5032:

Hey @fitzgen! During experiments with Kotlin Wasm WASI on Wasmtime I found several issues.
The code is here and produced Wasm file is here. Executed by running dev version of wasmtime:

wasmtime -W function-references,gc -D logging=y kotlin.wasm

Overall, every line from the example above produces an error on it's own :)

First four lines produces the following stack trace:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:387:14:
id from different slab
stack backtrace:
   0:        0x103470b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x10348f690 - core::fmt::write::ha36a8060c13608ea
   2:        0x10346c724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x103471b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x103471718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x1034725e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x103472010 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x103471020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x103471cd8 - _rust_begin_unwind
   9:        0x10350d854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x10350d824 - core::option::expect_failed::h1b731afdb81ee447
  11:        0x102b395d8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x104747638 - <unknown>

And the last line produces the following:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:203:9:
assertion failed: index <= Slab::<()>::MAX_CAPACITY
stack backtrace:
   0:        0x105b98b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x105bb7690 - core::fmt::write::ha36a8060c13608ea
   2:        0x105b94724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x105b99b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x105b99718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x105b9a5e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x105b99fe8 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x105b99020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x105b99cd8 - _rust_begin_unwind
   9:        0x105c35854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x105c358c0 - core::panicking::panic::hee236ca94fc05047
  11:        0x1052615a8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x106e6fd18 - <unknown>

Hope this is fine to leave this here :)

view this post on Zulip Wasmtime GitHub notifications bot (Nov 18 2024 at 17:24):

whyoleg edited a comment on issue #5032:

Hey @fitzgen! During experiments with Kotlin Wasm WASI on Wasmtime I found several issues.
The code is here and produced Wasm file is here. Executed by running dev version of wasmtime:

wasmtime -W function-references,gc -D logging=y kotlin.wasm

Overall, every line from the example above produces an error on it's own :)

First four lines produces the following stack trace:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:387:14:
id from different slab
stack backtrace:
   0:        0x103470b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x10348f690 - core::fmt::write::ha36a8060c13608ea
   2:        0x10346c724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x103471b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x103471718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x1034725e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x103472010 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x103471020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x103471cd8 - _rust_begin_unwind
   9:        0x10350d854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x10350d824 - core::option::expect_failed::h1b731afdb81ee447
  11:        0x102b395d8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x104747638 - <unknown>

And the last line produces the following:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:203:9:
assertion failed: index <= Slab::<()>::MAX_CAPACITY
stack backtrace:
   0:        0x105b98b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x105bb7690 - core::fmt::write::ha36a8060c13608ea
   2:        0x105b94724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x105b99b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x105b99718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x105b9a5e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x105b99fe8 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x105b99020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x105b99cd8 - _rust_begin_unwind
   9:        0x105c35854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x105c358c0 - core::panicking::panic::hee236ca94fc05047
  11:        0x1052615a8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x106e6fd18 - <unknown>

It works with Node.js and WasmEdge and outputs:

Class@687611678
[1, 2, 3]
[REALTIME, MONOTONIC]
true
true

687611678 is a hash code, so it could change per execution

Hope this is fine to leave this here :)


Last updated: Nov 22 2024 at 16:03 UTC