lock before using fCacheKeys in ~SkImageFilter()

No other code can be using an SkImageFilter() while it's being
destroyed, so there's not a chance of a race per-se here.  But, because
we have not acquired fMutex, there is technically a possibility that the
destructor sees an outdated version of fCacheKeys, not necessarily
reflecting the last change(s) made while another core held the mutex.

This is an unlikely case, but it's worth fixing by locking in the
destructor.  This will always be uncontended, and so very cheap.

Bug: skia:7666

Change-Id: I9f705bc6e8e99162b90d59b30b8dd51c4f238970
Reviewed-on: https://skia-review.googlesource.com/115929
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>

1 files changed, 1 insertions, 0 deletions

diff --git a/src/core/SkImageFilter.cpp b/src/core/SkImageFilter.cpp
index ae3b53a69e..815a78260e 100644
--- a/src/core/SkImageFilter.cpp
+++ b/src/core/SkImageFilter.cpp
@@ -168,6 +168,7 @@ SkImageFilter::SkImageFilter(sk_sp<SkImageFilter> const* inputs,
 }
 
 SkImageFilter::~SkImageFilter() {
+    SkAutoMutexAcquire lock(fMutex);
     SkImageFilterCache::Get()->purgeByKeys(fCacheKeys.begin(), fCacheKeys.count());
 }