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>
diff --git a/src/gpu/GrContext.cpp b/src/gpu/GrContext.cpp
index 405668d..0197eaa 100644
--- a/src/gpu/GrContext.cpp
+++ b/src/gpu/GrContext.cpp
@@ -381,7 +381,9 @@
fp = fContext->createUPMToPMEffect(std::move(fp), useConfigConversionEffect);
}
fp = GrFragmentProcessor::SwizzleOutput(std::move(fp), tempDrawInfo.fSwizzle);
- SkASSERT(fp);
+ if (!fp) {
+ return false;
+ }
if (tempProxy->priv().hasPendingIO()) {
this->flush(tempProxy.get());
@@ -508,7 +510,9 @@
unpremul = false;
}
fp = GrFragmentProcessor::SwizzleOutput(std::move(fp), tempDrawInfo.fSwizzle);
- SkASSERT(fp);
+ if (!fp) {
+ return false;
+ }
GrPaint paint;
paint.addColorFragmentProcessor(std::move(fp));