Stream: git-wasmtime

Topic: wasmtime / Issue #1490 Implement interrupting wasm code, ...

Wasmtime GitHub notifications bot (Apr 09 2020 at 19:32):

github-actions[bot] commented on Issue #1490:

Subscribe to Label Action

This issue or pull request has been labeled: "cranelift", "fuzzing", "wasmtime:api", "wasmtime:c-api"

<details> <summary>Users Subscribed to "cranelift"</summary>

• @bnjbvr

</details>
<details> <summary>Users Subscribed to "fuzzing"</summary>

• @fitzgen

</details>
<details> <summary>Users Subscribed to "wasmtime:api"</summary>

• @peterhuene

</details>
<details> <summary>Users Subscribed to "wasmtime:c-api"</summary>

• @peterhuene

</details>

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.

Wasmtime GitHub notifications bot (Apr 09 2020 at 19:46):

fitzgen commented on Issue #1490:

Haven't looked at the code yet, but I have a question:

The wasmtime::Store type has a
method to acquire an InterruptHandle,

Does this mean that the finest granularity of interrupt is a store?

That seems fine for now, in the single-threaded wasm world, but will likely need reworking to be finer grained when we support threads. Do you have an idea how much more work it would be to make this per-instance?

Wasmtime GitHub notifications bot (Apr 09 2020 at 19:47):

alexcrichton commented on Issue #1490:

@fitzgen yeah adapting this shouldn't be too hard at all, it's just a shared Arc data structure and it would be easy to arrange all instances linked together to have access to that Arc

Wasmtime GitHub notifications bot (Apr 09 2020 at 20:05):

github-actions[bot] commented on Issue #1490:

Subscribe to Label Action

This issue or pull request has been labeled: "wasi"

<details> <summary>Users Subscribed to "wasi"</summary>

• @kubkon

</details>

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.

Wasmtime GitHub notifications bot (Apr 17 2020 at 22:05):

alexcrichton commented on Issue #1490:

Ok I've pushed up a commit which uses a GlobalValue for the stack limit instead of a closure, and there's a "mini interpreter" of this GlobalValue since ins().global_value(...) can't be used this late after legalization. It's hopefully sufficient enough for now but also with better future-compatibility.

I'm not really sure how to serialize this out or parse it in the text format. If that's required can folks point me in the right direction of how to do that?

Wasmtime GitHub notifications bot (Apr 17 2020 at 22:08):

bjorn3 commented on Issue #1490:

You should serialize it in write_function and then parse it in cranelift-reader.

Wasmtime GitHub notifications bot (Apr 20 2020 at 15:11):

alexcrichton commented on Issue #1490:

Ok @sunfishcode, should be updated!

Wasmtime GitHub notifications bot (Apr 20 2020 at 15:50):

alexcrichton commented on Issue #1490:

Ok after some discussion with @sunfishcode I brought back the SA_ONSTACK flag so we can be sure to still execute the fallback to libstd's segfault handler on the sigaltstack. We already have the code to make the sigaltstack bigger, so that should cover our own purposes for now as well. This means that all signals still go through the sigaltstack.

Wasmtime GitHub notifications bot (Apr 20 2020 at 20:53):

alexcrichton commented on Issue #1490:

Ok the last commit should be the stack limit parsing via the syntax you suggested

Wasmtime GitHub notifications bot (Apr 21 2020 at 03:54):

sunfishcode commented on Issue #1490:

Looks good! There's now just the two CI failures. One is an easy fix I just commented on above.

There other is a failure in host_segfault.rs on macos-latest CI:

     Running target/release/deps/host_segfault-de61d05b549d9afb

thread 'main' panicked at 'assertion failed: stderr.contains("thread 'main' has overflowed its stack")', tests/host_segfault.rs:95:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: host_segfault::main
   8: std::rt::lang_start::{{closure}}
   9: std::panicking::try::do_call
  10: __rust_maybe_catch_panic
  11: std::rt::lang_start_internal
  12: main

Wasmtime GitHub notifications bot (Apr 21 2020 at 17:43):

alexcrichton commented on Issue #1490:

Ok all green now!

Wasmtime GitHub notifications bot (Apr 21 2020 at 18:03):

sunfishcode commented on Issue #1490:

Great!

Last updated: Oct 23 2024 at 20:03 UTC