Stream: git-wasmtime

Topic: wasmtime / Issue #2185 Expand modules instantiated in ins...

Wasmtime GitHub notifications bot (Sep 03 2020 at 19:28):

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

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

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

Learn more.
</details>

Wasmtime GitHub notifications bot (Sep 08 2020 at 17:27):

alexcrichton commented on Issue #2185:

I thought of doing so yeah, but I figured it'd be simpler to have only one way to ensure limited execution rather than relying on a combination of wasm-opt -ttf implicitly doing this, wasm-smith valid modules implicitly doing this, and wasm-smith possibly invalid modules requiring a thread. The threaded case was the least common denominator in that situation and I didn't think it was all that expensive.

I also wasn't really sure how this would impact oss-fuzz. It seems like it's easier if we only have one fuzz target but if it runs more in parallel then we could get more benefit from more of them. It felt a little overkill though to write more fuzz targets for tweaking what could also be a fuzz input option. I'm fine either way though! Do you prefer a separate fuzz target for this?

Wasmtime GitHub notifications bot (Sep 08 2020 at 17:41):

fitzgen commented on Issue #2185:

I think it is worth having a fuzz target that uses ensure_termination and not a timer thread because it is deterministic.

Can we make both instantiate_with_config and instantiate_with_timeout?

Wasmtime GitHub notifications bot (Sep 08 2020 at 17:55):

alexcrichton commented on Issue #2185:

Ok yeah determinism seems reasonable, I'll make that change soon

Wasmtime GitHub notifications bot (Sep 08 2020 at 21:28):

alexcrichton commented on Issue #2185:

Ok, updated!

Last updated: Dec 23 2024 at 12:05 UTC