Stream: git-wasmtime

Topic: wasmtime / PR #2485 Restrict threads spawned during fuzzing


view this post on Zulip Wasmtime GitHub notifications bot (Dec 07 2020 at 22:41):

alexcrichton opened PR #2485 from fuzz-less-threads to main:

I was having limited success fuzzing locally because apparently the
fuzzer was spawning too many threads. Looking into it that indeed
appears to be the case! The threads which time out runtime of wasm only
exit after the sleep has completely finished, meaning that if we execute
a ton of wasm that exits quickly each run will generate a sleeping thread.

This commit fixes the issue by using some synchronization to ensure the
sleeping thread exits when our fuzzed run also exits.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 00:47):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 00:47):

fitzgen created PR Review Comment:

What if there is a spurious wake up? Something that isn't related to the fuzz target completing. I think there should be an atomic or something that gets set on drop as well, and then this here should while !atomic.load() { cvar.wait_timeout(); }.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 00:47):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 15:55):

alexcrichton updated PR #2485 from fuzz-less-threads to main:

I was having limited success fuzzing locally because apparently the
fuzzer was spawning too many threads. Looking into it that indeed
appears to be the case! The threads which time out runtime of wasm only
exit after the sleep has completely finished, meaning that if we execute
a ton of wasm that exits quickly each run will generate a sleeping thread.

This commit fixes the issue by using some synchronization to ensure the
sleeping thread exits when our fuzzed run also exits.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 15:55):

alexcrichton created PR Review Comment:

It makes it a bit more complicated to handle adjustments to the timeout and such, and given the nondeterministic nature of a timeout I figured it wouldn't matter too much, but I went ahead and added in handling of spurious wakeups.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 15:55):

alexcrichton submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 16:34):

alexcrichton merged PR #2485.


Last updated: Dec 23 2024 at 12:05 UTC