wasm: add fuzzer test files

wasm: add fuzzer test files

Using the following invocations:
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug --no-presubmit --extra-flags="--dump-wasm-module --dump-wasm-module-path=./test/fuzzer/wasm/" unittests
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug --no-presubmit --extra-flags="--dump-wasm-module --dump-wasm-module-path=./test/fuzzer/wasm/" mjsunit/wasm/*
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug --no-presubmit --extra-flags="--dump-wasm-module --dump-wasm-module-path=./test/fuzzer/wasm/" $(cd test/; ls cctest/wasm/test-*.cc | sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org, aizatsky@chromium.org, jochen@chromium.org

[JF, 2016-03-22 18:23:27]

Description was changed from

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org
==========

to

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org
==========

[JF, 2016-03-22 18:23:27]

jfb@chromium.org changed reviewers:
+ aizatsky@chromium.org

[JF, 2016-03-22 18:23:47]

Added aizatsky at kcc's request.

[aizatsky, 2016-03-22 18:28:03]

This is what we need.


lgtm

[JF, 2016-03-22 18:31:10]

Description was changed from

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org
==========

to

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

[JF, 2016-03-22 18:31:10]

jfb@chromium.org changed reviewers:
+ jochen@chromium.org

[JF, 2016-03-22 18:31:48]

OK great, adding jochen for V8 lgtm. Wanted to make sure those were the right
bits in the right place first.

[JF, 2016-03-22 18:32:29]

The CQ bit was checked by jfb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-22 18:32:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826513002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826513002/1

[commit-bot: I haz the power, 2016-03-22 18:34:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-22 18:34:27]

Dry run: Try jobs failed on following builders:
  v8_android_arm_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...)
  v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/...)
  v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/...)
  v8_linux64_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/3342)
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)
  v8_linux_arm_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel/builds/15760)
  v8_linux_dbg_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/3355)
  v8_linux_gcc_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...)
  v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
  v8_linux_mipsel_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel...)
  v8_linux_nodcheck_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel/build...)
  v8_linux_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/3355)
  v8_mac_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/17480)
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/12776)

[JF, 2016-03-22 18:41:02]

It looks like the bots aren't happy with some of the files:

  File "/b/depot_tools/apply_issue.py", line 322, in <module>
    sys.exit(main())
  File "/b/depot_tools/apply_issue.py", line 235, in main
    patchset = rietveld_obj.get_patch(issue_to_apply, patchset_to_apply)
  File "/b/depot_tools/rietveld.py", line 157, in get_patch
    'Binary file is empty. Maybe the file wasn\'t uploaded in the '
patch.UnsupportedPatchFormat: Can't process patch for file
test/fuzzer/wasm/a2b7893bed8ca3d5.ok.wasm.
Binary file is empty. Maybe the file wasn't uploaded in the first place?


Maybe it's something with size? I know libfuzzer would rather have smaller
files, I could keep them to under a certain size if that makes sense?

Here's the current size distribution:

 1.2M
  91K
  24K
  24K
  21K
 7.0K
 2.9K
 2.7K
 2.6K
 1.2K
  867
  572
  409
  316
  305
  279
  267
  249
  243
  242
  242
  242
  242
  242
  242
  242
  242
  242
  242
  234
  232
  209
  209
  209
  204
  201
  201
  201
  197
  194
  189
  189
  186
  184
  184
  183
  182
  182
  182
  181
  177
  176
  171
  171
  171
  168
  167
  166
  166
  161
  158
  158
  158
  157
  154
  154
  153
  153
  153
  153
  153
  152
  152
  151
  150
  149
  148
  146
  145
  144
  144
  144
  142
  142
  142
  141
  141
  139
  139
  139
  138
  138
  136
  136
  135
  135
  135
  135
  131
  130
  130
  129
  124
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  122
  119
  119
  119
  118
  116
  115
  114
  114
  114
  114
  114
  114
  114
  113
  113
  113
  113
  111
  109
  108
  108
  108
  107
  106
  106
  103
   99
   99
   99
   99
   93
   92
   91
   90
   89
   85
   85
   78
   74
   74
   70
   69
   69
   69
   69
   69
   69
   69
   67
   66
   66
   66
   65
   64
   62
   61
   57
   57
   57
   56
   56
   56
   55
   55
   55
   54
   54
   53
   53
   52
   52
   52
   51
   51
   51
   50
   50
   50
   49
   49
   49
   49
   48
   48
   48
   48
   47
   47
   47
   47
   46
   46
   46
   46
   45
   45
   45
   44
   44
   44
   43
   43
   43
   43
   43
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   42
   41
   41
   41
   41
   41
   41
   41
   41
   40
   40
   40
   40
   39
   39
   39
   39
   38
   38
   38
   38
   38
   37
   37
   37
   37
   36
   36
   36
   36
   36
   36
   35
   35
   35
   35
   34
   34
   34
   34
   34
   33
   33
   33
   33
   33
   32
   32
   32
   32
   31
   31
   31
   31
   30
   30
   30
   30
   30
   29
   29
   29
   29
   29
   29
   28
   28
   28
   28
   28
   27
   27
   27
   27
   27
   26
   26
   26
   26
   26
   25
   25
   25
   25
   25
   25
   25
   24
   24
   24
   24
   24
   24
   24
   23
   23
   23
   23
   23
   23
   23
   22
   22
   22
   22
   22
   22
   21
   21
   21
   21
   21
   21
   21
   20
   20
   20
   19
   19
   19
   19
   19
   19
   18
   18
   18
   18
   17
   17
   17
   16
   16
   16
   15
   15
   15
   14
   14
   14
   14
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   13
   12
   12
   12
   11
   11
   11
   10
   10
   10
   10
    9
    9
    9
    7

[aizatsky, 2016-03-22 18:54:24]

up to 20k is probably fine if this is what it takes for input to be interesting.
Megabytes is definitely too excessive, but it will not be used unless you define
max_len that big (which we won't).

[bradn, 2016-03-22 20:07:37]

bradnelson@google.com changed reviewers:
+ bradnelson@google.com

[bradn, 2016-03-22 20:07:39]

Just to clarify, landing these here is the right place to feed things?

Also, we have a second mode of operation in the wasm_asmjs directory, but
probably could start with the same seed data, as it's a similar format. Should
be produce separate date for this, or is there a way to share for both?

[aizatsky, 2016-03-22 20:39:32]

> Just to clarify, landing these here is the right place to feed things?

I think having these next to fuzzers is a good idea.

[bradn, 2016-03-22 20:45:44]

Sorry, not being clear in my questions :-)

Is this a location that we can put seed data that will get automatically picked
up in the future when the format changes, or is there a manual step on your end?

(I.e. is there somewhere in src/chrome/src/testing/fuzzing that we need to
reference this data)

Also any thoughts on sharing these for the wasm_asmjs fuzzer target?

Thanks!

[JF, 2016-03-22 20:45:45]

Description was changed from

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

to

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
  find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

[JF, 2016-03-22 20:47:24]

On 2016/03/22 18:54:24, aizatsky wrote:
> up to 20k is probably fine if this is what it takes for input to be
interesting.
> Megabytes is definitely too excessive, but it will not be used unless you
define
> max_len that big (which we won't).

Done, I removed the 5 files that were larger:
  find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

I updated the CL description to reflect this. I can add a shell script to a
future CL if we end up re-generating this often (the format will eventually be
stable, we're only churning it before stable launch).

[JF, 2016-03-22 20:47:51]

The CQ bit was checked by jfb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-22 20:48:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826513002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826513002/20001

[commit-bot: I haz the power, 2016-03-22 21:01:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-22 21:01:56]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/...)
  v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/...)

[JF, 2016-03-22 21:16:30]

Ha, looks like some of the bots already run these tests and are finding issues!
We won't be able to commit this CL before fixing the issues. I'm happy to look
into some of them.

[JF, 2016-03-23 19:31:26]

Description was changed from

==========
wasm: add fuzzer test files

Files generated using the new run-tests.py option added in:
  https://codereview.chromium.org/1828433002

Using the following invocations:
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ unittests
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ mjsunit/wasm/*
  ./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64
--mode=debug --no-presubmit --dump-wasm-module
--dump-wasm-module-path=test/fuzzer/wasm/ $(cd test/; ls cctest/wasm/test-*.cc |
sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
  find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

to

==========
wasm: add fuzzer test files

Using the following invocations:
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" unittests
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" mjsunit/wasm/*
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" $(cd test/; ls
cctest/wasm/test-*.cc | sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
  find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

[JF, 2016-03-23 19:32:38]

Talked to titzer and bradnelson: we'll fix the bugs in the near future, but not
now since we have a few other pressing matters.

I'll therefore put this CL on ice for now, but should get back to it before 52
branches because it's needed for asm2wasm testing.

[JF, 2016-05-05 17:59:33]

The CQ bit was checked by jfb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-05 17:59:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826513002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826513002/60001

[JF, 2016-05-05 18:00:00]

Description was changed from

==========
wasm: add fuzzer test files

Using the following invocations:
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" unittests
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" mjsunit/wasm/*
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" $(cd test/; ls
cctest/wasm/test-*.cc | sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
  find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

to

==========
wasm: add fuzzer test files

Using the following invocations:
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" unittests
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" mjsunit/wasm/*
./tools/run-tests.py -j8 --variants=default --timeout=10 --arch=x64 --mode=debug
--no-presubmit --extra-flags="--dump-wasm-module
--dump-wasm-module-path=./test/fuzzer/wasm/" $(cd test/; ls
cctest/wasm/test-*.cc | sed -es/wasm\\///g | sed -es/[.]cc/\\/\\*/g)
find ./test/fuzzer/wasm/ -type f -size +20k | xargs rm

The files will need to be regenerated as we change the binary format.

R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org,
aizatsky@chromium.org, jochen@chromium.org
==========

[commit-bot: I haz the power, 2016-05-05 18:18:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-05 18:18:08]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[JF, 2016-06-17 20:35:29]

The CQ bit was checked by jfb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-17 20:35:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826513002/80001

[JF, 2016-06-17 20:36:10]

bradnelson suggested I update these tests and do another dry run since there
have been a few fixes in the recent past. Here's to hoping! ;-)

[commit-bot: I haz the power, 2016-06-17 20:54:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-17 20:54:33]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[JF, 2016-06-17 21:06:08]

The two interesting logs from the Linux run:

https://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng_triggered/....

Command: /tmp/isolated_run47s5C7/out/Debug/v8_simple_wasm_fuzzer
--random-seed=-1038184575 fuzzer/wasm/d88cff7166ed466f.ok.wasm

Build environment:
 GYP_DEFINES: dcheck_always_on=1 fastbuild=1 target_arch=ia32
test_isolation_mode=prepare use_goma=1 v8_enable_slow_dchecks=1
v8_optimized_debug=1 v8_target_arch=ia32
 GYP_GENERATORS: ninja

Run #1
Exit code: -11
Result: CRASH


https://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng_triggered/....


Command: /tmp/isolated_runL844gm/out/Debug/v8_simple_wasm_fuzzer
--random-seed=-1038184575 fuzzer/wasm/de466929fe7c6001.ok.wasm

Build environment:
 GYP_DEFINES: dcheck_always_on=1 fastbuild=1 target_arch=ia32
test_isolation_mode=prepare use_goma=1 v8_enable_slow_dchecks=1
v8_optimized_debug=1 v8_target_arch=ia32
 GYP_GENERATORS: ninja

Run #1
Exit code: -6
Result: FAIL

Stderr:
/b/build/slave/linux/build/v8/build/linux/debian_wheezy_i386-sysroot/usr/lib/gcc/i486-linux-gnu/4.6/../../../../include/c++/4.6313:
    error: attempt to subscript container with out-of-bounds index 0, but     
    container only holds 0 elements.

Objects involved in the operation:
sequence "this" @ 0x0xfff1ae44 {
}

[JF, 2016-06-17 21:41:18]

I looked at the out of bounds thing, and it looks like the fuzzer isn't set up
the same way as main code so it ends up with an import_table but without the
corresponding import_code.

InstantiateModuleCommon calls WasmModule::Instantiate which does a bunch of the
heavy lifting, but the fuzzer goes through CompileAndRunWasmModule which seems
to duplicate a bunch of Instantiate but forgets to call
CompileWrappersToImportedFunctions (which should be empty when fuzzing, and
should therefore fail, but we may want to also fuzz it non-empty). Why are
things duplicated this way?

[JF, 2016-06-17 21:59:59]

The crash is stack exhaustion. bradnelson says he'll add the explicit stack
checks, off by default, and on for fuzzing only. This will fix itself with trap
handler.

[bradn, 2016-08-24 23:23:06]

The CQ bit was checked by bradnelson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-24 23:23:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-25 00:19:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-25 00:19:42]

Dry run: This issue passed the CQ dry run.

[titzer, 2016-09-12 17:21:33]

titzer@chromium.org changed reviewers:
- titzer@chromium.org

[bradn, 2016-09-19 19:58:31]

Landed a different way. Closing.