[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-9427-gc2be6fc

ap at apple.com ap at apple.com
Wed Dec 22 12:56:33 UTC 2010


The following commit has been merged in the debian/experimental branch:
commit 141322f01d43ad15403a98b1cb630136284f7154
Author: ap at apple.com <ap at apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Thu Sep 2 12:57:58 2010 +0000

    2010-09-02  Alexey Proskuryakov  <ap at apple.com>
    
            Reviewed by Oliver Hunt.
    
            https://bugs.webkit.org/show_bug.cgi?id=43230
            <rdar://problem/8254215> REGRESSION: Memory leak within JSParser::JSParser
    
            One can't delete a ThreadSpecific object that has data in it. It's not even possible to
            enumerate data objects in all threads, much less destroy them from a thread that's destroying
            the ThreadSpecific.
    
            * parser/JSParser.cpp:
            (JSC::JSParser::JSParser):
            * runtime/JSGlobalData.h:
            * wtf/WTFThreadData.cpp:
            (WTF::WTFThreadData::WTFThreadData):
            * wtf/WTFThreadData.h:
            (WTF::WTFThreadData::approximatedStackStart):
            Moved stack guard tracking from JSGlobalData to WTFThreadData.
    
            * wtf/ThreadSpecific.h: Made destructor unimplemented. It's dangerous, and we probably won't
            ever face a situation where we'd want to delete a ThreadSpecific object.
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@66665 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/JavaScriptCore/ChangeLog b/JavaScriptCore/ChangeLog
index 5dab16d..1cf4ccd 100644
--- a/JavaScriptCore/ChangeLog
+++ b/JavaScriptCore/ChangeLog
@@ -1,3 +1,26 @@
+2010-09-02  Alexey Proskuryakov  <ap at apple.com>
+
+        Reviewed by Oliver Hunt.
+
+        https://bugs.webkit.org/show_bug.cgi?id=43230
+        <rdar://problem/8254215> REGRESSION: Memory leak within JSParser::JSParser
+
+        One can't delete a ThreadSpecific object that has data in it. It's not even possible to
+        enumerate data objects in all threads, much less destroy them from a thread that's destroying
+        the ThreadSpecific.
+
+        * parser/JSParser.cpp:
+        (JSC::JSParser::JSParser):
+        * runtime/JSGlobalData.h: 
+        * wtf/WTFThreadData.cpp:
+        (WTF::WTFThreadData::WTFThreadData):
+        * wtf/WTFThreadData.h:
+        (WTF::WTFThreadData::approximatedStackStart):
+        Moved stack guard tracking from JSGlobalData to WTFThreadData.
+
+        * wtf/ThreadSpecific.h: Made destructor unimplemented. It's dangerous, and we probably won't
+        ever face a situation where we'd want to delete a ThreadSpecific object.
+
 2010-09-01  Gavin Barraclough  <barraclough at apple.com>
 
         Rubber stamped by Oliver Hunt.
diff --git a/JavaScriptCore/parser/JSParser.cpp b/JavaScriptCore/parser/JSParser.cpp
index 3baceba..6852de1 100644
--- a/JavaScriptCore/parser/JSParser.cpp
+++ b/JavaScriptCore/parser/JSParser.cpp
@@ -33,6 +33,7 @@ using namespace JSC;
 #include "NodeInfo.h"
 #include "ASTBuilder.h"
 #include <wtf/HashFunctions.h>
+#include <wtf/WTFThreadData.h>
 #include <utility>
 
 using namespace std;
@@ -220,12 +221,7 @@ JSParser::JSParser(Lexer* lexer, JSGlobalData* globalData, SourceProvider* provi
     , m_nonLHSCount(0)
     , m_syntaxAlreadyValidated(provider->isValid())
 {
-    m_endAddress = *(globalData->stackGuards);
-    if (!m_endAddress) {
-        char sample = 0;
-        m_endAddress = &sample - kMaxParserStackUsage;
-        *(globalData->stackGuards) = m_endAddress;
-    }
+    m_endAddress = wtfThreadData().approximatedStackStart() - kMaxParserStackUsage;
     next();
     m_lexer->setLastLineNumber(tokenLine());
 }
diff --git a/JavaScriptCore/runtime/JSGlobalData.h b/JavaScriptCore/runtime/JSGlobalData.h
index 07acb43..43c4bab 100644
--- a/JavaScriptCore/runtime/JSGlobalData.h
+++ b/JavaScriptCore/runtime/JSGlobalData.h
@@ -227,7 +227,6 @@ namespace JSC {
 #endif
 
         CachedTranscendentalFunction<sin> cachedSin;
-        WTF::ThreadSpecific<char*> stackGuards;
 
         void resetDateCache();
 
diff --git a/JavaScriptCore/wtf/ThreadSpecific.h b/JavaScriptCore/wtf/ThreadSpecific.h
index 893f561..93ed466 100644
--- a/JavaScriptCore/wtf/ThreadSpecific.h
+++ b/JavaScriptCore/wtf/ThreadSpecific.h
@@ -67,12 +67,17 @@ public:
     T* operator->();
     operator T*();
     T& operator*();
-    ~ThreadSpecific();
 
 private:
 #if !USE(PTHREADS) && !PLATFORM(QT) && !PLATFORM(GTK) && OS(WINDOWS)
     friend void ThreadSpecificThreadExit();
 #endif
+
+    // Not implemented. It's technically possible to destroy a thread specific key, but one would need
+    // to make sure that all values have been destroyed already (usually, that all threads that used it
+    // have exited). It's unlikely that any user of this call will be in that situation - and having
+    // a destructor defined can be confusing, given that it has such strong pre-requisites to work correctly.
+    ~ThreadSpecific();
     
     T* get();
     void set(T*);
@@ -116,11 +121,6 @@ inline ThreadSpecific<T>::ThreadSpecific()
 }
 
 template<typename T>
-inline ThreadSpecific<T>::~ThreadSpecific()
-{
-}
-
-template<typename T>
 inline T* ThreadSpecific<T>::get()
 {
     return m_value;
@@ -143,12 +143,6 @@ inline ThreadSpecific<T>::ThreadSpecific()
 }
 
 template<typename T>
-inline ThreadSpecific<T>::~ThreadSpecific()
-{
-    pthread_key_delete(m_key); // Does not invoke destructor functions.
-}
-
-template<typename T>
 inline T* ThreadSpecific<T>::get()
 {
     Data* data = static_cast<Data*>(pthread_getspecific(m_key));
@@ -170,12 +164,6 @@ inline ThreadSpecific<T>::ThreadSpecific()
 }
 
 template<typename T>
-inline ThreadSpecific<T>::~ThreadSpecific()
-{
-    // Does not invoke destructor functions. QThreadStorage will do it
-}
-
-template<typename T>
 inline T* ThreadSpecific<T>::get()
 {
     Data* data = static_cast<Data*>(m_key.localData());
@@ -199,12 +187,6 @@ inline ThreadSpecific<T>::ThreadSpecific()
 }
 
 template<typename T>
-inline ThreadSpecific<T>::~ThreadSpecific()
-{
-    g_static_private_free(&m_key);
-}
-
-template<typename T>
 inline T* ThreadSpecific<T>::get()
 {
     Data* data = static_cast<Data*>(g_static_private_get(&m_key));
diff --git a/JavaScriptCore/wtf/WTFThreadData.cpp b/JavaScriptCore/wtf/WTFThreadData.cpp
index 729b48e..702baed 100644
--- a/JavaScriptCore/wtf/WTFThreadData.cpp
+++ b/JavaScriptCore/wtf/WTFThreadData.cpp
@@ -43,6 +43,8 @@ WTFThreadData::WTFThreadData()
     , m_currentIdentifierTable(m_defaultIdentifierTable)
 #endif
 {
+    char sample = 0;
+    m_approximatedStackStart = &sample;
 }
 
 WTFThreadData::~WTFThreadData()
diff --git a/JavaScriptCore/wtf/WTFThreadData.h b/JavaScriptCore/wtf/WTFThreadData.h
index c596260..20ffaca 100644
--- a/JavaScriptCore/wtf/WTFThreadData.h
+++ b/JavaScriptCore/wtf/WTFThreadData.h
@@ -112,6 +112,11 @@ public:
     }
 #endif
 
+    char* approximatedStackStart() const
+    {
+        return m_approximatedStackStart;
+    }
+
 private:
     AtomicStringTable* m_atomicStringTable;
     AtomicStringTableDestructor m_atomicStringTableDestructor;
@@ -128,6 +133,8 @@ private:
 #endif
     friend WTFThreadData& wtfThreadData();
     friend class AtomicStringTable;
+
+    char* m_approximatedStackStart;
 };
 
 inline WTFThreadData& wtfThreadData()

-- 
WebKit Debian packaging



More information about the Pkg-webkit-commits mailing list