Adjust fuzzing behavior for triangulator/dashing
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 <[email protected]>
Reviewed-by: Jim Van Verth <[email protected]>
Commit-Queue: Michael Ludwig <[email protected]>
diff --git a/fuzz/FuzzTriangulation.cpp b/fuzz/FuzzTriangulation.cpp
index a2162f9..b62054c 100644
--- a/fuzz/FuzzTriangulation.cpp
+++ b/fuzz/FuzzTriangulation.cpp
@@ -28,6 +28,8 @@
GrCpuVertexAllocator allocator;
bool isLinear;
- GrTriangulator::PathToTriangles(path, tol, clipBounds, &allocator, &isLinear);
- allocator.detachVertexData(); // normally handled by the triangulating path renderer.
+ int count = GrTriangulator::PathToTriangles(path, tol, clipBounds, &allocator, &isLinear);
+ if (count > 0) {
+ allocator.detachVertexData(); // normally handled by the triangulating path renderer.
+ }
}
