Implement fuzzing of VP9 depacketization.

Implement fuzzing of VP9 depacketization.

Provides an example for how to use fuzzing within the webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/62e9bda7bf0fb52f7c672e8a589007091755cbbe

[pbos-webrtc, 2015-11-19 14:33:20]

PTAL.

aizatsky@: Can we split up the upstream BUILD file to have libfuzzer_main
separate? Or put the binaries under "if (build_fuzzer_binaries)" or something?

Right now we can't depend on it the target because it's in a file with test
binaries pulling in //base and other dependencies that are not available in the
webrtc checkout.

We need to be able to build fuzzer binaries in our tree and run in our checkouts
to promote more of them being constructed. :)

Reviewers:
aizatsky@ for how to resolve the libfuzzer_main dependency.
kjellander@ for the BUILD.gn setup and OWNERS.
asapersson@ for vp9_decoder_fuzzer.cc (which is pretty simple)

[pbos-webrtc, 2015-11-19 14:37:13]

fix build file + comment webrtc_fuzzer_main.cc

[pbos-webrtc, 2015-11-19 14:38:58]

Description was changed from

==========
Implement fuzzing of VP9 depacketization.

This looks clean, also an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:5229
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

to

==========
Implement fuzzing of VP9 depacketization.

This looks clean, also an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

[pbos-webrtc, 2015-11-19 14:48:53]

remove include

[pbos-webrtc, 2015-11-19 14:51:36]

Description was changed from

==========
Implement fuzzing of VP9 depacketization.

This looks clean, also an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

to

==========
Implement fuzzing of VP9 depacketization.

This looks clean but is also an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

[pbos-webrtc, 2015-11-19 14:52:19]

Description was changed from

==========
Implement fuzzing of VP9 depacketization.

This looks clean but is also an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

to

==========
Implement fuzzing of VP9 depacketization.

Provides an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

[pbos-webrtc, 2015-11-19 14:52:41]

Description was changed from

==========
Implement fuzzing of VP9 depacketization.

Provides an example for how to use fuzzing within the
webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

to

==========
Implement fuzzing of VP9 depacketization.

Provides an example for how to use fuzzing within the webrtc tree.

BUG=webrtc:4771
R=aizatsky@chromium.org, asapersson@webrtc.org, kjellander@webrtc.org
==========

[kjellander_webrtc, 2015-11-19 15:23:06]

Even if we talked about only adding a GN target offline, I think I prefer having
GYP targets as well for now. It can't be that hard to write.
We don't cover that many configurations with GN, so going GN-only will have to
wait.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD.gn
File webrtc/test/fuzzers/BUILD.gn (right):

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:18:
"../../../third_party/llvm/lib/Fuzzer/FuzzerCrossOver.cpp",
I believe the right thing to do about these sources is to add a BUILD.gn file in
Chromium's
src/build/secondary/third_party/llvm and put the sources into a libfuzzer target
there.
That of course would require us to wait for the revision to be rolled down to
WebRTC, but that happens three times a day now.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:43: "../../modules/rtp_rtcp/",
Remove leading slash.

[kjellander_webrtc, 2015-11-19 15:29:44]

Chatted offline and GN-only is fine for this use case. But I'd like the
libfuzzer target to be properly setup.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD.gn
File webrtc/test/fuzzers/BUILD.gn (right):

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:43: "../../modules/rtp_rtcp/",
On 2015/11/19 15:23:06, kjellander (webrtc) wrote:
> Remove leading slash.

*sigh* I meant trailing slash.

[pbos-webrtc, 2015-11-19 15:37:44]

feedback + removed webrtc:: (offline feedback)

[pbos-webrtc, 2015-11-19 15:39:26]

For posterity: Reason to use gn is because that's the only thing available for
upstream libFuzzer in Chromium. As for coverage I don't think this should run
under our infra but rather ClusterFuzz, we just have to make sure it pulls in
our suite of fuzzers.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD.gn
File webrtc/test/fuzzers/BUILD.gn (right):

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:18:
"../../../third_party/llvm/lib/Fuzzer/FuzzerCrossOver.cpp",
On 2015/11/19 15:23:06, kjellander (webrtc) wrote:
> I believe the right thing to do about these sources is to add a BUILD.gn file
in
> Chromium's
> src/build/secondary/third_party/llvm and put the sources into a libfuzzer
target
> there.
> That of course would require us to wait for the revision to be rolled down to
> WebRTC, but that happens three times a day now.

That's not a problem, I expect to rebase this about once or twice before it
lands. I wanted to put this up to show aizatsky@ what my current option was (and
I don't like it) to see if we can do something about this dependency upstream.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:43: "../../modules/rtp_rtcp/",
On 2015/11/19 15:29:44, kjellander (webrtc) wrote:
> On 2015/11/19 15:23:06, kjellander (webrtc) wrote:
> > Remove leading slash.
> 
> *sigh* I meant trailing slash.

Done.

[kjellander_webrtc, 2015-11-19 16:18:41]

Please add the comment/TODO and I'll approve.

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD.gn
File webrtc/test/fuzzers/BUILD.gn (right):

https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
webrtc/test/fuzzers/BUILD.gn:18:
"../../../third_party/llvm/lib/Fuzzer/FuzzerCrossOver.cpp",
On 2015/11/19 15:39:25, pbos-webrtc wrote:
> On 2015/11/19 15:23:06, kjellander (webrtc) wrote:
> > I believe the right thing to do about these sources is to add a BUILD.gn
file
> in
> > Chromium's
> > src/build/secondary/third_party/llvm and put the sources into a libfuzzer
> target
> > there.
> > That of course would require us to wait for the revision to be rolled down
to
> > WebRTC, but that happens three times a day now.
> 
> That's not a problem, I expect to rebase this about once or twice before it
> lands. I wanted to put this up to show aizatsky@ what my current option was
(and
> I don't like it) to see if we can do something about this dependency upstream.

Then at least add a comment/TODO about that these should be covered by a target
in 
src/build/secondary/third_party/llvm/BUILD.gn in Chromium (which we could reuse
here).

[pbos-webrtc, 2015-11-19 16:19:45]

On 2015/11/19 16:18:41, kjellander (webrtc) wrote:
> Please add the comment/TODO and I'll approve.
> 
>
https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD.gn
> File webrtc/test/fuzzers/BUILD.gn (right):
> 
>
https://codereview.webrtc.org/1463523002/diff/40001/webrtc/test/fuzzers/BUILD...
> webrtc/test/fuzzers/BUILD.gn:18:
> "../../../third_party/llvm/lib/Fuzzer/FuzzerCrossOver.cpp",
> On 2015/11/19 15:39:25, pbos-webrtc wrote:
> > On 2015/11/19 15:23:06, kjellander (webrtc) wrote:
> > > I believe the right thing to do about these sources is to add a BUILD.gn
> file
> > in
> > > Chromium's
> > > src/build/secondary/third_party/llvm and put the sources into a libfuzzer
> > target
> > > there.
> > > That of course would require us to wait for the revision to be rolled down
> to
> > > WebRTC, but that happens three times a day now.
> > 
> > That's not a problem, I expect to rebase this about once or twice before it
> > lands. I wanted to put this up to show aizatsky@ what my current option was
> (and
> > I don't like it) to see if we can do something about this dependency
upstream.
> 
> Then at least add a comment/TODO about that these should be covered by a
target
> in 
> src/build/secondary/third_party/llvm/BUILD.gn in Chromium (which we could
reuse
> here).

I don't want to submit this before we've figured out what to do upstream, so
I'll wait for aizatsky@ to see this. :)

[pbos-webrtc, 2015-11-20 12:55:32]

base webrtc_fuzzer_main on //testing/libfuzzer:libfuzzer_main

[pbos-webrtc, 2015-11-20 12:59:28]

move use_libfuzzer conditional to webrtc/BUILD.gn to have it picked up in
Chromium

[pbos-webrtc, 2015-11-20 13:00:54]

PTAL, I now depend on //testing/libfuzzer in Chromium. It's under a
use_libfuzzer conditional matching Chromium

[kjellander_webrtc, 2015-11-20 13:04:48]

*.gn: lgtm! Thanks for using //testing target instead.

[åsapersson, 2015-11-20 13:16:24]

vp9_decoder_fuzzer.cc: lgtm

[aizatsky, 2015-11-20 19:54:22]

lgtm

[pbos-webrtc, 2015-11-23 13:45:02]

added sanitizers.gni for default values

[pbos-webrtc, 2015-11-23 13:45:42]

kjellander@ can you check PS#7?

[commit-bot: I haz the power, 2015-11-23 14:12:17]

Patchset 7 (id:??) landed as
https://crrev.com/62e9bda7bf0fb52f7c672e8a589007091755cbbe
Cr-Commit-Position: refs/heads/master@{#10752}

[pbos-webrtc, 2015-11-23 14:12:18]

Committed patchset #7 (id:120001) manually as
62e9bda7bf0fb52f7c672e8a589007091755cbbe (presubmit successful).