Avoid unsafe use of SkRefCnt::getRefCnt() in ImagesManager

The function isn't threadsafe, so races would occur and certain textures
wouldn't be removed from ImagesManager's master list. The list would then be
iterated over, all items dereferenced, and bad times would ensue.

The SkRefCnt class uses atomic inc/dec to decide when to destroy an object, but
reading such an integer non-atomically isn't safe. Instead use the real signal
we're looking for - when the ImageTexture is deleted - to know when to remove
the ImageTexture from ImagesManager's list.

Mutual exclusion from editing the list is now maintained by only unref-ing the
ImageTexture within releaseImage, which holds the ImagesManager's m_imagesLock
(which we already do anyway).

bug:6859278
Change-Id: I75ebf79f2617484e7df355d6539226ce64882369

1 files changed, 3 insertions, 0 deletions

diff --git a/Source/WebCore/platform/graphics/android/rendering/ImagesManager.h b/Source/WebCore/platform/graphics/android/rendering/ImagesManager.h
index b915a46..718cfdd 100644
--- a/Source/WebCore/platform/graphics/android/rendering/ImagesManager.h
+++ b/Source/WebCore/platform/graphics/android/rendering/ImagesManager.h
@@ -47,6 +47,9 @@ public:
     ImageTexture* retainImage(unsigned imgCRC);
     void releaseImage(unsigned imgCRC);
 
+    // should be called only by ~ImageTexture()
+    void onImageTextureDestroy(unsigned imgCRC);
+
     bool prepareTextures(GLWebViewState*);
     int nbTextures();