summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlex Crichton <alex@alexcrichton.com>2020-02-04 17:09:39 -0600
committerGitHub <noreply@github.com>2020-02-04 15:09:38 -0800
commit33f92aa06fe5de7bcf9f6b7fe2e74ba5e8e1e782 (patch)
treed6fb8a78e204ac1044075c7c3fa42afc0c1ebce6
parente0a449672a372aced4d11b4d60a49293d413a9bb (diff)
downloadbinaryen-33f92aa06fe5de7bcf9f6b7fe2e74ba5e8e1e782.tar.gz
binaryen-33f92aa06fe5de7bcf9f6b7fe2e74ba5e8e1e782.tar.bz2
binaryen-33f92aa06fe5de7bcf9f6b7fe2e74ba5e8e1e782.zip
Avoid an infinite loop in `-ttf` generation (#2637)
We've been throwing some fuzzing at some wasm implementations recently and one of our strategies is to use `wasm-opt -ttf` with the fuzzer's input to generate a wasm module. Some of our tests, though, have been failing due to out-of-memory while `wasm-opt` is generating a module. This loop appears to be infinitely executing since the input just-so-happens that `oneIn(3)` returns true for every byte of the input file, or at least enough such that when the xor factor is merged in it at least generates very long sequence of `true`. It looks like elsewhere in the file when `while (oneIn(N))` is used it's also guarded by `!finishedInput`, so I've added a similar guard here as well.
-rw-r--r--src/tools/fuzzing.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/tools/fuzzing.h b/src/tools/fuzzing.h
index e21c6a14d..96dd43826 100644
--- a/src/tools/fuzzing.h
+++ b/src/tools/fuzzing.h
@@ -596,7 +596,7 @@ private:
wasm.addExport(export_);
}
// add some to the table
- while (oneIn(3)) {
+ while (oneIn(3) && !finishedInput) {
wasm.table.segments[0].data.push_back(func->name);
}
// cleanup