Fix crash in QQuickPixmapData::release()

Previously, if the reader was deleted (eg, via engine destruction)
the reply might be deleted without letting the associated
QQuickPixmapData know about it.  If that data was later released,
it would attempt to write to previously freed memory.

This commit ensures that the data's reply ptr is set to zero when
the reply is deleted by the reader dtor.  It also adds a comment to
the reply dtor to explain why it is important.

A unit test for this issue already exists:
tst_qquickpixmapcache::lockingCrash() run under valgrind.

Change-Id: Icd94528e1336db1c00b118b3f6d1222eef402c46
Reviewed-by: Martin Jones <martin.jones@nokia.com>

diff --git a/src/quick/util/qquickpixmapcache.cpp b/src/quick/util/qquickpixmapcache.cpp
index 3b9c59e..592def1 100644 (file)
--- a/src/quick/util/qquickpixmapcache.cpp
+++ b/src/quick/util/qquickpixmapcache.cpp
@@ -374,6 +374,8 @@ QQuickPixmapReader::~QQuickPixmapReader()
     mutex.lock();
     // manually cancel all outstanding jobs.
     foreach (QQuickPixmapReply *reply, jobs) {
+        if (reply->data && reply->data->reply == reply)
+            reply->data->reply = 0;
         delete reply;
     }
     jobs.clear();
@@ -838,6 +840,8 @@ QQuickPixmapReply::QQuickPixmapReply(QQuickPixmapData *d)
 
 QQuickPixmapReply::~QQuickPixmapReply()
 {
+    // note: this->data->reply must be set to zero if this->data->reply == this
+    // but it must be done within mutex locking, to be guaranteed to be safe.
 }
 
 bool QQuickPixmapReply::event(QEvent *event)