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.
fitzgen submitted PR Review.
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(); }
.
fitzgen submitted PR Review.
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.
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.
alexcrichton submitted PR Review.
alexcrichton merged PR #2485.
Last updated: Nov 22 2024 at 16:03 UTC