summaryrefslogtreecommitdiffstats
path: root/src/3rdparty
diff options
context:
space:
mode:
authorSimon Hausmann <simon.hausmann@nokia.com>2012-01-05 10:47:52 (GMT)
committerSimon Hausmann <simon.hausmann@nokia.com>2012-01-05 10:47:52 (GMT)
commit4e73732d3e72ea59d39ec5a5c01c2e76bbff7dc1 (patch)
treef6ffd105c8281ced809289d8356b8bb07837910e /src/3rdparty
parente87db399c27bfd325fb502b7b30db1dce9b87fa5 (diff)
downloadQt-4e73732d3e72ea59d39ec5a5c01c2e76bbff7dc1.zip
Qt-4e73732d3e72ea59d39ec5a5c01c2e76bbff7dc1.tar.gz
Qt-4e73732d3e72ea59d39ec5a5c01c2e76bbff7dc1.tar.bz2
Fix crash when creating a QScriptEngine in a native thread
The change in http://trac.webkit.org/changeset/48412/ introduced a fix to avoid leaking thread specific data by ensuring get() on ThreadSpecific works even during the thread destruction phase. The fix worked by setting the local data again. However as we can see in the backtrace from QTBUG-22926, the local data should not be set unconditionally, otherwise our destroy function will be called recursively when the local data is still set. Task-number: QTBUG-22926 Reviewed-by: Kent Hansen Tested-and-Reviewed-by: Andy Shaw
Diffstat (limited to 'src/3rdparty')
-rw-r--r--src/3rdparty/javascriptcore/JavaScriptCore/wtf/ThreadSpecific.h3
1 files changed, 2 insertions, 1 deletions
diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/wtf/ThreadSpecific.h b/src/3rdparty/javascriptcore/JavaScriptCore/wtf/ThreadSpecific.h
index 7e5679f..3f0e764 100644
--- a/src/3rdparty/javascriptcore/JavaScriptCore/wtf/ThreadSpecific.h
+++ b/src/3rdparty/javascriptcore/JavaScriptCore/wtf/ThreadSpecific.h
@@ -256,7 +256,8 @@ inline void ThreadSpecific<T>::destroy(void* ptr)
#endif
#if PLATFORM(QT)
// See comment as above
- data->owner->m_key.setLocalData(data);
+ if (!data->owner->m_key.hasLocalData())
+ data->owner->m_key.setLocalData(data);
#endif
data->value->~T();