Change-Id: I3fd20d2b69d5c3b4b7163c239d65185ce9099c41
Reviewed-on: https://skia-review.googlesource.com/c/171783
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Hal Canary <halcanary@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Doesn't look like we need to distinguish these if we just
write them as the simple
1) load the right number of bytes
2) clamp to [min,max]
This makes enum fuzzing independent of its underlying type, and may make
it easier to see the mapping from fuzzed byte stream to
nextRange()/nextEnum() values.
Change-Id: I9f785f94f513a0087ad7151b5e7bc14ddbe9314a
Reviewed-on: https://skia-review.googlesource.com/c/171820
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
I think this originally was done due to int / unsigned
differences between Linux in Windows. In hindsight, that
was short-sighted.
Bug: oss-fuzz:11281,oss-fuzz:11282,oss-fuzz:11283
Change-Id: I06e38cb663f84278f479eb7fee3118c1068eeaa8
Reviewed-on: https://skia-review.googlesource.com/c/169244
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Make FuzzEnum always use uint32_t to make it consistent
(we were seeing some Windows setups have underlying type return
int and not unsigned int that we saw on Linux)
Bug: 897455
Change-Id: Ia8c97e59bb498d959a9a30abcb61731f4bd145cf
Reviewed-on: https://skia-review.googlesource.com/c/164240
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Some oss-fuzz bugs (like the linked one) would not reproduce
in Skia proper due to the fact that there were subtle overloads
of the various Fuzz::next() methods in FuzzCanvas.cpp that
were pulled in in Skia proper, but not oss-fuzz.
This puts all of them in to FuzzCommon.h and makes the
matrix and rrect ones opt-in (fuzz_matrix, fuzz_rrect).
Additionally, this renames fuzz.cpp -> FuzzMain.cpp so we
can properly include Fuzz.cpp in oss-fuzz without
having two mains.
Bug: oss-fuzz:10378
Change-Id: I6cf9afb471781b9fadb689482109a1e5662358b5
Reviewed-on: https://skia-review.googlesource.com/154900
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 2a2f675926.
Reason for revert: this appears to be what is holding up the Chrome roll.
Original change's description:
> SkTypes: extract SkTo
>
> Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09
> Reviewed-on: https://skia-review.googlesource.com/133620
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Iafd738aedfb679a23c061a51afe4b98a8d4cdfae
Reviewed-on: https://skia-review.googlesource.com/134504
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Spun off from the SkTFitsIn CL.
Change-Id: I686d680df6a36ebc02db3847ad5e2cedcbcd67ef
Reviewed-on: https://skia-review.googlesource.com/134083
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This also includes a helper "fuzzer" for making a corpus.
Point it at an image or folder of images and it will
decode those images and write the SkPixmap's bytes to
disk, such that the fuzzer will be able to read in
those bytes as if it had decoded the image (or gotten
it from another source).
Bug: skia:
Change-Id: Iaf223a39078f2b62908fb47929add5d63f22d973
Reviewed-on: https://skia-review.googlesource.com/117367
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This shouldn't matter... But I just feel the impulsion to fix it.
Bug: skia:
Change-Id: Id3b6302071165b3abe98a3d89409d39715fac23c
Reviewed-on: https://skia-review.googlesource.com/111002
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Prevents logging from cluttering the stats.
Better handles limited memory.
Bug: skia:
Change-Id: I12c1a46875fd9120938cab520ef70de69c451ad8
Reviewed-on: https://skia-review.googlesource.com/110642
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Also Remove ScaleToSides, which we hadn't been running for a while.
Bug: skia:
Change-Id: I772dad722c34681392d5b635b3de716f3b00d597
Reviewed-on: https://skia-review.googlesource.com/110443
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Also refactor a few things to make it easier to use oss-fuzz.
Bug: skia:
Change-Id: Ie518a6cfc7d57a347b5d09089379f986d33f8b7f
Reviewed-on: https://skia-review.googlesource.com/41740
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This will be rolled out in three stages:
1) make SkMemory.h and have SkTypes.h include it.
2) Adjust chromium and android.
3) no long include SkMemory.h in SkTypes.h
Change-Id: If360ef5e1164d88f50b03f279e2e963ca2f57d5d
Reviewed-on: https://skia-review.googlesource.com/9874
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Herb Derby <herb@google.com>
run `fuzz --type pdf_canvas` or `fuzz --type null_canvas` or
`fuzz --type n32_canvas`
Change-Id: Id70179d5578ed1e67006aef7823bf75fc1d7a4a6
Reviewed-on: https://skia-review.googlesource.com/8418
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
BUG=skia:
Change-Id: Ie7d4fac3024b361a281f456fec2b3a837e2bfe43
Reviewed-on: https://skia-review.googlesource.com/6881
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Make the fuzzRange not crash if min == max, just set n to be min.
BUG=skia:
Change-Id: I138cefbec9b408d3b35e4258d770e6b396af0e5f
Reviewed-on: https://skia-review.googlesource.com/5305
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
We use this approach instead of T next() because different compilers
evaluate function parameters in different orders. If fuzz->next()
returned 5 and then 7, foo(fuzz->next(), fuzz->next()) would be
foo(5, 7) when compiled on GCC and foo(7, 5) when compiled on Clang.
By requiring params to be passed in, we avoid the temptation to call
next() in a way that does not consume fuzzed bytes in a single
platform-independent order.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4392
Change-Id: I35de849f82e8be45378f662a48100eb732fa8895
Reviewed-on: https://skia-review.googlesource.com/4392
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
signalBoring() no longer exists. When the fuzzer runs out of randomness,
it just returns 0. Fuzzers should not go into infinite loops if this
happens. do while loops are particularly error-prone.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3963
Change-Id: Iebcfc14cc6b0a19c5dd015cd39875c81fa44003e
Reviewed-on: https://skia-review.googlesource.com/3963
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
With the move from SkData::NewXXX to SkData::MakeXXX most
SkAutoTUnref<SkData> were changed to sk_sp<SkData>. However,
there are still a few SkAutoTUnref<SkData> around, so clean
them up.
Review-Url: https://codereview.chromium.org/2212493002
Instead of a single ASSERT macro, this switches to two new methods:
- signalBug(): tell afl-fuzz there's a bug caused by its inputs (by crashing)
- signalBoring(): tell afl-fuzz these inputs are not worth testing (by exiting gracefully)
I'm not seeing any effect on fuzz/s when I just always log verbosely.
signalBug() now triggers SIGSEGV rather than SIGABRT. This should make it work with catchsegv more easily.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1585353002
Review URL: https://codereview.chromium.org/1585353002
Try to start faster:
- remove flags dependency
- print nothing
- strip unused symbols from the binary on Mac (smaller binary)
- only create one fuzz object
- only run one DEF_FUZZ
I am not sure if any of these things mattered, but I thought you may like to look.
Good stuff:
- make nextU() / nextF() work
- drop nextURange() / nextFRange() for now
- add nextB() for a single byte
As you may have guessed, I have figured out how to use afl-fuzz on my laptop.
Syntax to run becomes:
$ afl-fuzz ... out/Release/fuzz <DEF_FUZZ name> @@
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1581203003
Review URL: https://codereview.chromium.org/1581203003
