[SCM] WebKit Debian packaging branch, debian/experimental, updated. debian/1.3.8-1-1049-g2e11a8e

barraclough at apple.com barraclough at apple.com
Fri Jan 21 15:08:26 UTC 2011


The following commit has been merged in the debian/experimental branch:
commit d6544ee55dbf8adfa9aa6951db30a3a98fa04324
Author: barraclough at apple.com <barraclough at apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Fri Jan 7 21:04:21 2011 +0000

    Source/JavaScriptCore: [GTK] Port scrollbar painting to GtkStyleContext
    https://bugs.webkit.org/show_bug.cgi?id=52051
    
    Patch by Carlos Garcia Campos <cgarcia at igalia.com> on 2011-01-07
    Reviewed by Martin Robinson.
    
    * wtf/gobject/GTypedefs.h: Add GtkStyleContext forward
    declaration.
    
    WebCore: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebCore.exp.in:
    * bindings/js/DOMWrapperWorld.cpp:
    (WebCore::DOMWrapperWorld::DOMWrapperWorld):
    (WebCore::DOMWrapperWorld::~DOMWrapperWorld):
    (WebCore::DOMWrapperWorld::clearWrappers):
    * bindings/js/DOMWrapperWorld.h:
    
    WebKit/mac: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebView/WebScriptWorld.mm:
    (-[WebScriptWorld unregisterWorld]):
    
    WebKit/win: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebScriptWorld.cpp:
    (WebScriptWorld::unregisterWorld):
    
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75265 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog
index 2f66994..52dc6a9 100644
--- a/Source/JavaScriptCore/ChangeLog
+++ b/Source/JavaScriptCore/ChangeLog
@@ -26,6 +26,31 @@
 
 2011-01-06  Gavin Barraclough  <barraclough at apple.com>
 
+        Reviewed by Geoff Garen.
+
+        Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
+
+        The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
+        destructor early, in order to release wrappers once we know we no longer intend to use them.
+        Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
+        lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
+        A sequence of events that triggers the bug would look like this:
+
+        (1) Create a DOMWrapperWorld.
+        (2) Register a timer in the world.
+        (3) Call unregisterWorld() on the world.
+        (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
+        (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
+            called forgetWorld() none exists.
+        (6) Attempt to add a wrapper to a NULL map.
+
+        Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
+
+        * runtime/WeakGCMap.h:
+        (JSC::WeakGCMap::clear):
+
+2011-01-06  Gavin Barraclough  <barraclough at apple.com>
+
         Reviewed by Darin Adler.
 
         Bug 52021 - zeroDouble broken on ARMv7
diff --git a/Source/JavaScriptCore/runtime/WeakGCMap.h b/Source/JavaScriptCore/runtime/WeakGCMap.h
index 39a91c5..6b96a74 100644
--- a/Source/JavaScriptCore/runtime/WeakGCMap.h
+++ b/Source/JavaScriptCore/runtime/WeakGCMap.h
@@ -49,6 +49,7 @@ public:
     typedef typename HashMap<KeyType, MappedType>::const_iterator const_iterator;
     
     bool isEmpty() { return m_map.isEmpty(); }
+    void clear() { m_map.clear(); }
 
     MappedType get(const KeyType& key) const;
     pair<iterator, bool> set(const KeyType&, const MappedType&); 
diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
index 3222f30..ae0d5fa 100644
--- a/WebCore/ChangeLog
+++ b/WebCore/ChangeLog
@@ -1,3 +1,32 @@
+2011-01-06  Gavin Barraclough  <barraclough at apple.com>
+
+        Reviewed by Geoff Garen.
+
+        Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
+
+        The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
+        destructor early, in order to release wrappers once we know we no longer intend to use them.
+        Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
+        lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
+        A sequence of events that triggers the bug would look like this:
+
+        (1) Create a DOMWrapperWorld.
+        (2) Register a timer in the world.
+        (3) Call unregisterWorld() on the world.
+        (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
+        (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
+            called forgetWorld() none exists.
+        (6) Attempt to add a wrapper to a NULL map.
+
+        Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
+
+        * WebCore.exp.in:
+        * bindings/js/DOMWrapperWorld.cpp:
+        (WebCore::DOMWrapperWorld::DOMWrapperWorld):
+        (WebCore::DOMWrapperWorld::~DOMWrapperWorld):
+        (WebCore::DOMWrapperWorld::clearWrappers):
+        * bindings/js/DOMWrapperWorld.h:
+
 2011-01-07  Chris Marrin  <cmarrin at apple.com>
 
         Rubber-stamped by Simon Fraser.
diff --git a/WebCore/WebCore.exp.in b/WebCore/WebCore.exp.in
index aac7dde..da2d78c 100644
--- a/WebCore/WebCore.exp.in
+++ b/WebCore/WebCore.exp.in
@@ -344,7 +344,7 @@ __ZN7WebCore14SecurityOrigin40setDomainRelaxationForbiddenForURLSchemeEbRKN3WTF6
 __ZN7WebCore14SecurityOrigin6createERKN3WTF6StringES4_i
 __ZN7WebCore14SecurityOrigin6createERKNS_4KURLEi
 __ZN7WebCore15ArchiveResource6createEN3WTF10PassRefPtrINS_12SharedBufferEEERKNS_4KURLERKNS1_6StringESA_SA_RKNS_16ResourceResponseE
-__ZN7WebCore15DOMWrapperWorld15unregisterWorldEv
+__ZN7WebCore15DOMWrapperWorld13clearWrappersEv
 __ZN7WebCore15DOMWrapperWorldD1Ev
 __ZN7WebCore15DatabaseTracker12deleteOriginEPNS_14SecurityOriginE
 __ZN7WebCore15DatabaseTracker14deleteDatabaseEPNS_14SecurityOriginERKN3WTF6StringE
diff --git a/WebCore/bindings/js/DOMWrapperWorld.cpp b/WebCore/bindings/js/DOMWrapperWorld.cpp
index 10c3fdd..13ee37a 100644
--- a/WebCore/bindings/js/DOMWrapperWorld.cpp
+++ b/WebCore/bindings/js/DOMWrapperWorld.cpp
@@ -32,30 +32,14 @@ namespace WebCore {
 DOMWrapperWorld::DOMWrapperWorld(JSC::JSGlobalData* globalData, bool isNormal)
     : m_globalData(globalData)
     , m_isNormal(isNormal)
-    , m_isRegistered(false)
-{
-    registerWorld();
-}
-
-DOMWrapperWorld::~DOMWrapperWorld()
-{
-    unregisterWorld();
-}
-
-void DOMWrapperWorld::registerWorld()
 {
     JSGlobalData::ClientData* clientData = m_globalData->clientData;
     ASSERT(clientData);
     static_cast<WebCoreJSClientData*>(clientData)->rememberWorld(this);
-    m_isRegistered = true;
 }
 
-void DOMWrapperWorld::unregisterWorld()
+DOMWrapperWorld::~DOMWrapperWorld()
 {
-    if (!m_isRegistered)
-        return;
-    m_isRegistered = false;
-
     JSGlobalData::ClientData* clientData = m_globalData->clientData;
     ASSERT(clientData);
     static_cast<WebCoreJSClientData*>(clientData)->forgetWorld(this);
@@ -68,6 +52,19 @@ void DOMWrapperWorld::unregisterWorld()
         (*m_scriptControllersWithWindowShells.begin())->destroyWindowShell(this);
 }
 
+void DOMWrapperWorld::clearWrappers()
+{
+    m_wrappers.clear();
+    m_stringCache.clear();
+
+    // These items are created lazily.
+    while (!m_documentsWithWrapperCaches.isEmpty())
+        (*m_documentsWithWrapperCaches.begin())->destroyWrapperCache(this);
+
+    while (!m_scriptControllersWithWindowShells.isEmpty())
+        (*m_scriptControllersWithWindowShells.begin())->destroyWindowShell(this);
+}
+
 DOMWrapperWorld* normalWorld(JSC::JSGlobalData& globalData)
 {
     JSGlobalData::ClientData* clientData = globalData.clientData;
diff --git a/WebCore/bindings/js/DOMWrapperWorld.h b/WebCore/bindings/js/DOMWrapperWorld.h
index 35b68fc..5e7b551 100644
--- a/WebCore/bindings/js/DOMWrapperWorld.h
+++ b/WebCore/bindings/js/DOMWrapperWorld.h
@@ -42,9 +42,9 @@ public:
         return adoptRef(new DOMWrapperWorld(globalData, isNormal));
     }
     ~DOMWrapperWorld();
-    
-    void registerWorld();
-    void unregisterWorld();
+
+    // Free as much memory held onto by this world as possible.
+    void clearWrappers();
 
     void didCreateWrapperCache(Document* document) { m_documentsWithWrapperCaches.add(document); }
     void didDestroyWrapperCache(Document* document) { m_documentsWithWrapperCaches.remove(document); }
@@ -66,7 +66,6 @@ private:
     HashSet<Document*> m_documentsWithWrapperCaches;
     HashSet<ScriptController*> m_scriptControllersWithWindowShells;
     bool m_isNormal;
-    bool m_isRegistered;
 };
 
 DOMWrapperWorld* normalWorld(JSC::JSGlobalData&);
diff --git a/WebKit/mac/ChangeLog b/WebKit/mac/ChangeLog
index 5b212aa..9ce17eb 100644
--- a/WebKit/mac/ChangeLog
+++ b/WebKit/mac/ChangeLog
@@ -1,3 +1,28 @@
+2011-01-06  Gavin Barraclough  <barraclough at apple.com>
+
+        Reviewed by Geoff Garen.
+
+        Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
+
+        The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
+        destructor early, in order to release wrappers once we know we no longer intend to use them.
+        Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
+        lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
+        A sequence of events that triggers the bug would look like this:
+
+        (1) Create a DOMWrapperWorld.
+        (2) Register a timer in the world.
+        (3) Call unregisterWorld() on the world.
+        (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
+        (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
+            called forgetWorld() none exists.
+        (6) Attempt to add a wrapper to a NULL map.
+
+        Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
+
+        * WebView/WebScriptWorld.mm:
+        (-[WebScriptWorld unregisterWorld]):
+
 2011-01-04  Chris Fleizach  <cfleizach at apple.com>
 
         Reviewed by Sam Weinig.
diff --git a/WebKit/mac/WebView/WebScriptWorld.mm b/WebKit/mac/WebView/WebScriptWorld.mm
index 8ca6f44..61daff1 100644
--- a/WebKit/mac/WebView/WebScriptWorld.mm
+++ b/WebKit/mac/WebView/WebScriptWorld.mm
@@ -77,7 +77,7 @@ static WorldMap& allWorlds()
 
 - (void)unregisterWorld
 {
-    _private->world->unregisterWorld();
+    _private->world->clearWrappers();
 }
 
 - (void)dealloc
diff --git a/WebKit/win/ChangeLog b/WebKit/win/ChangeLog
index 8d07352..d0f0fe3 100644
--- a/WebKit/win/ChangeLog
+++ b/WebKit/win/ChangeLog
@@ -1,3 +1,28 @@
+2011-01-06  Gavin Barraclough  <barraclough at apple.com>
+
+        Reviewed by Geoff Garen.
+
+        Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
+
+        The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
+        destructor early, in order to release wrappers once we know we no longer intend to use them.
+        Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
+        lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
+        A sequence of events that triggers the bug would look like this:
+
+        (1) Create a DOMWrapperWorld.
+        (2) Register a timer in the world.
+        (3) Call unregisterWorld() on the world.
+        (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
+        (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
+            called forgetWorld() none exists.
+        (6) Attempt to add a wrapper to a NULL map.
+
+        Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
+
+        * WebScriptWorld.cpp:
+        (WebScriptWorld::unregisterWorld):
+
 2011-01-07  Chris Marrin  <cmarrin at apple.com>
 
         Rubber-stamped by Simon Fraser.
diff --git a/WebKit/win/WebScriptWorld.cpp b/WebKit/win/WebScriptWorld.cpp
index 9c661d9..6a35571 100644
--- a/WebKit/win/WebScriptWorld.cpp
+++ b/WebKit/win/WebScriptWorld.cpp
@@ -139,6 +139,6 @@ HRESULT WebScriptWorld::scriptWorldForGlobalContext(JSGlobalContextRef context,
 
 HRESULT WebScriptWorld::unregisterWorld()
 {
-    m_world->unregisterWorld();
+    m_world->clearWrappers();
     return S_OK;
 }

-- 
WebKit Debian packaging



More information about the Pkg-webkit-commits mailing list