Speculative "fix" for crash in analyzeProcessors

From the bug it looks like a null fragment processors may be getting into the processor set. This CL tries to plug any gaps in our fragmentProcessor handling.

The only real substantive part to this CL is the addition of some "if (!fp) { return nullptr; }" blocks.

Everything else is just to add chokepoints for processor allocation.

Bug: 734076
Change-Id: I4952b1a05bc6690d5aa09de977fa6dc54c80338a
Reviewed-on: https://skia-review.googlesource.com/21267
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

1 files changed, 3 insertions, 1 deletions

diff --git a/tests/GLProgramsTest.cpp b/tests/GLProgramsTest.cpp
index cfa5561564..4a89d0a9bf 100644
--- a/tests/GLProgramsTest.cpp
+++ b/tests/GLProgramsTest.cpp
@@ -217,7 +217,9 @@ static void set_random_color_coverage_stages(GrPaint* paint,
     const float procTreeProbability = 0.5f;
     if (d->fRandom->nextF() < procTreeProbability) {
         sk_sp<GrFragmentProcessor> fp(create_random_proc_tree(d, 2, maxTreeLevels));
-        paint->addColorFragmentProcessor(std::move(fp));
+        if (fp) {
+            paint->addColorFragmentProcessor(std::move(fp));
+        }
     } else {
         int numProcs = d->fRandom->nextULessThan(maxStages + 1);
         int numColorProcs = d->fRandom->nextULessThan(numProcs + 1);