Bug 36932:
Adds a lower limit when fuzzing dash path effects, since it can produce
paths with > 140k verbs. While this is not that much memory on its own,
the triangulating path renderer can require 3+GB to complete its work
(although it doesn't actually fail).
Bug 36945, 37042:
Also has PathToTriangles check for finite paths before starting any
triangulation work. These paths were created with infinities and NaNs.
Normally such a path would be rejected at a higher level in SkCanvas.
Since the triangulator is being fuzzed directly, this emulates this.
It's included in GrTriangulator and not the fuzzer's main function
because it's a cheap test and theoretically we could encounter a path
that was built lower down (e.g. dashing or transformed to device space)
that then overflowed.
Bug: oss-fuzz:36923, oss-fuzz:36945, oss-fuzz:37042
Change-Id: If97212bf410f771b42cebaedb5733af1abbfc4b2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449520
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This is the other half of making everything in gpu/ops be v1-only.
Bug: skia:11837
Change-Id: I5d77a499ef02eba69208d5bd634650433d02f6fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440216
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
It took a few "independent" changes in order to get the linked fuzzer
bugs to pass without failing. Leaving any out triggered an issue :/
1. I changed nearly_flat to be <= epsilon, since if it's == epsilon and
we split the edge, then the new coordinates would have
difference < epsilon.
2. I updated double_to_clamped_scalar to also snap very small values to
0 (right now 16 * float epsilon).
3. double_to_clamped_scalar is now used to clean up the computed
intersection of two edges, and is used to process all initial
vertices (in case the curve evaluation generates lots of denormals
etc.)
4. I updated the use of nearly_flat in checkForIntersection to report
no intersection if both lines are nearly_flat. The comments suggest
nearly_flat means you can't split along that line since the new
coord is incalculable. So if both lines are flat, it's a really
tough numerical scenario and I just punt.
Then I made a few other changes for the fuzzer and debugging:
1. Added more logging messages and updated the code so that it compiles
correctly if TRIANGULATOR_LOGGING is defined.
2. I was also getting asserts in the fuzzer because the vertex
allocator expects the vertex buffer to be detached by the path
renderer before its destroyed, so I just have the fuzzer detach and
discard it. Running locally, the fuzzer test cases from the two
linked bugs pass successfully without oom'ing or timing out.
Bug: oss-fuzz:33672, oss-fuzz:33620
Change-Id: I7687b920db0a9e200b3fa79b323974b7812e52ff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404120
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
