The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.
I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.
R=clemensh@chromium.org
Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}
The EnableFlagScope is useful also for non-boolean flags. With the
template we can use if for example in the wasm fuzzers to reduce the
maximum memory size of a wasm module.
In addition I put the EnableFlagScope into the v8::internal namespace,
and I fixed a small typo.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: Iae5d5c058c334cd0f9e09d20adfd229fc2d6c585
Reviewed-on: https://chromium-review.googlesource.com/531005
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45862}
This is a testing-only function, which is semantically equivalent to a
SyncCompile followed by SyncInstantiate.
We add a new SyncCompileAndInstantiate function to do those two steps
in one go, and use this method instead.
For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
introduced.
This is part of our effort to reduce the number of special paths for
testing. It is connected with
https://chromium-review.googlesource.com/529210, but should not
conflict with it.
After landing both CLs, we can later also get rid of
InstantiateModuleForTesting.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
Reviewed-on: https://chromium-review.googlesource.com/529844
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45852}
Similar to the maximum memory size this limit caused problems for
the fuzzer due to oom issues. With the command line flag we can limit
the maximum table size for the fuzzer.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2648223004
Cr-Commit-Position: refs/heads/master@{#42623}
The hardcoded constant caused a problem for the wasm fuzzer because
when the maximum memory was allocated in a test case, clusterfuzz ran
out of memory. with the command line flag we can set a lower limit
for the fuzzer.
The flag has the value of the constant as its default value, so that
for everything but the fuzzers nothing should change.
R=titzer@chromium.org
BUG=chromium:676888
Review-Url: https://codereview.chromium.org/2626313003
Cr-Commit-Position: refs/heads/master@{#42599}
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
- Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
- Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.
R=mtrofin@chromium.org, ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
The wasm-module-runner is used both in cctests and in fuzzers. As
discussed offline, it is weird to include cctest header files in
fuzzers, so I introduce a new test/common directory which contains the
common files.
R=titzer@chromium.org, jochen@chromium.org
Review-Url: https://codereview.chromium.org/2335193002
Cr-Commit-Position: refs/heads/master@{#39411}
Moved the compilation/instantiation pipeline to work off the
module object (JSObject), making the compiled module data (the
FixedArray) an implementation detail. This:
- simplifies the code by removing duplicate decode->compile->instantiate
sequences
- sets up the stage for "dressing up" the runtime model with
stronger typed APIs
- helps relanding this CL: https://codereview.chromium.org/2305903002/.
It turns out that GCs during the cloning/instantiation events cause
trouble, and centering the source of truth on the module object helps
address this issue.
In the process, clarified cctest setup for wasm-capable isolates,
and changed signatures for consistency (using ModuleOrigin througout).
BUG=
Review-Url: https://codereview.chromium.org/2320723005
Cr-Commit-Position: refs/heads/master@{#39360}
With this CL the wasm-code-fuzzer first decodes and interprets the test
case generated by the fuzzer. It then compiles the test case, but only
executes the compiled instance if the interpretation of the test case
was successful. If the compiled instance is executed, then the result of
the execution is compared with the result of the interpretation.
Additionally this CL refactors the CompileAndRunWasmModule function in
wasm-module.cc to resuse code in the call to the interpreter.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2321443002
Cr-Commit-Position: refs/heads/master@{#39351}
Remove second wasm module compilation and instantiation path that
we had in CompileAndRunWasmModule and reuse the same path used
by user code.
BUG=
Review-Url: https://codereview.chromium.org/2091533002
Cr-Commit-Position: refs/heads/master@{#37203}
