Commit Graph

15 Commits

Author SHA1 Message Date
Kevin Lubick
d104266241 Fix fuzzRange
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>
2016-11-29 18:29:03 +00:00
Kevin Lubick
c9f0cc8700 Add back in min/max check on fuzzer range
BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4798

Change-Id: Ia93b4eeea82dd04f0c6bd287f61d26086a0aa740
Reviewed-on: https://skia-review.googlesource.com/4798
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
2016-11-16 19:17:19 +00:00
Kevin Lubick
fb0ce926e6 Properly handle INT_MIN and related
BUG=skia:5967

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4751

Change-Id: Ie846560ebdaf11e1a5247842b3549ade1e100af2
Reviewed-on: https://skia-review.googlesource.com/4751
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
2016-11-14 17:27:38 +00:00
Kevin Lubick
416b248312 Avoid platform-dependent function params in Fuzzer
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>
2016-11-10 22:52:03 +00:00
Kevin Lubick
2f535cecd0 Make fuzzers use cleaner interface
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>
2016-11-01 19:23:16 +00:00
kjlubick
840f12a721 Fix memory leak in FuzzGradients
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2446643003

Review-Url: https://codereview.chromium.org/2446643003
2016-10-25 06:11:05 -07:00
kjlubick
85d301745a Fix fuzzer's bools to be 0 or 1 only
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447823002

Review-Url: https://codereview.chromium.org/2447823002
2016-10-24 11:53:35 -07:00
reed
42943c8aa9 change SkStreams to work with sk_sp<SkData> instead of SkData*
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2333713002

Review-Url: https://codereview.chromium.org/2333713002
2016-09-12 12:01:44 -07:00
bungeman
ffae30db4a Convert SkAutoTUnref<SkData> to sk_sp<SkData>.
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
2016-08-03 13:32:32 -07:00
kjlubick
e565450d0b Port FuzzPathop from chromium
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2148023002

Review-Url: https://codereview.chromium.org/2148023002
2016-07-19 16:50:03 -07:00
kjlubick
4319593988 Do an in-place replacement of SkRandom with Fuzz for FilterFuzz
This feels rather clunky, because we aren't using the full potential of the
fuzzer, but it works, it seems.

BUG=skia:4969
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1710183002

Review URL: https://codereview.chromium.org/1710183002
2016-04-05 12:48:47 -07:00
kjlubick
5bd98a244b Create ParsePath API fuzz
This is based on https://codereview.chromium.org/1675053002

BUG=skia:4438
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1702383003

Review URL: https://codereview.chromium.org/1702383003
2016-02-18 06:27:39 -08:00
mtklein
a115942ed6 fuzz: signalBug() / signalBoring()
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
2016-01-15 05:46:54 -08:00
mtklein
24a22c7de8 some fuzz hacking
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
2016-01-14 04:59:42 -08:00
mtklein
65e5824d3a Add new fuzz binary.
This is designed to have short startup time, for maximum fuzzing throughput.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1589563002

Review URL: https://codereview.chromium.org/1589563002
2016-01-13 12:57:58 -08:00