JavaScriptCore:
authormjs <mjs@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 8 May 2006 04:59:28 +0000 (04:59 +0000)
committermjs <mjs@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 8 May 2006 04:59:28 +0000 (04:59 +0000)
        Reviewed and landed by Maciej.

        - fix http://bugzilla.opendarwin.org/show_bug.cgi?id=8765
        Random crashes on TOT since the form state change

        I haven't figured out how to construct a test for this, but this does seem to fix the
        problem; Mitz mentioned that a double-destroy was occurring in these functions.

        * kxmlcore/HashMap.h: (KXMLCore::HashMap::remove): Use RefCounter::deref instead of calling
        ~ValueType, because ~ValueType often results in a double-destroy, since the HashTable also
        destroys the element based on the storage type. The RefCounter template correctly does work
        only in cases where ValueType and ValueStorageType differe and this class is what's used
        elsewhere for the same purpose; I somehow missed this case when optimizing HashMap.
        * kxmlcore/HashSet.h: (KXMLCore::HashSet::remove): Ditto.

WebCore:

        Suggested by Mitz. Reviewed and landed by Maciej.

        * dom/Document.cpp: (WebCore::Document::formElementsState): Fixed mistake where the
        vector has an initial size and instead should have an initial capacity. Harmless in
        a way, but hurts performance.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@14221 268f45cc-cd09-0410-ab3c-d52691b4dbfc

JavaScriptCore/ChangeLog
JavaScriptCore/kxmlcore/HashMap.h
JavaScriptCore/kxmlcore/HashSet.h
WebCore/ChangeLog
WebCore/dom/Document.cpp

index e8573782ec59b1abeb7f2e7c0b8b903708c8a79a..1b7aae5d33b9cd9d8f6ce2b105682a00bf41ec5f 100644 (file)
@@ -1,3 +1,20 @@
+2006-05-06  Darin Adler  <darin@apple.com>
+
+        Reviewed and landed by Maciej.
+
+        - fix http://bugzilla.opendarwin.org/show_bug.cgi?id=8765
+        Random crashes on TOT since the form state change
+        
+        I haven't figured out how to construct a test for this, but this does seem to fix the
+        problem; Mitz mentioned that a double-destroy was occurring in these functions.
+        
+        * kxmlcore/HashMap.h: (KXMLCore::HashMap::remove): Use RefCounter::deref instead of calling
+        ~ValueType, because ~ValueType often results in a double-destroy, since the HashTable also
+        destroys the element based on the storage type. The RefCounter template correctly does work
+        only in cases where ValueType and ValueStorageType differe and this class is what's used
+        elsewhere for the same purpose; I somehow missed this case when optimizing HashMap.
+        * kxmlcore/HashSet.h: (KXMLCore::HashSet::remove): Ditto.
+        
 2006-05-05  Darin Adler  <darin@apple.com>
 
         - http://bugzilla.opendarwin.org/show_bug.cgi?id=8722
index a5881f7abd3663340a5c4878c5a5a92cdf7057c8..262dcbf24d376c8b5b4315f7fb616483343de4d6 100644 (file)
@@ -288,8 +288,7 @@ namespace KXMLCore {
     {
         if (it.m_impl == m_impl.end())
             return;
-        // Use "(*it)." instead of "it->" to work around a problem seen with the Visual C++ compiler.
-        (*it).~ValueType();
+        RefCounter<ValueTraits, ValueStorageTraits>::deref(*it.m_impl);
         m_impl.remove(it.m_impl);
     }
 
index 00f49385c2257717cf80f0b701f9c329302add5d..5c0b56bae5d8a2025d26e4dc8ccb7bf749b7152b 100644 (file)
@@ -274,8 +274,7 @@ namespace KXMLCore {
     {
         if (it.m_impl == m_impl.end())
             return;
-        // Use "(*it)." instead of "it->" to work around a problem seen with the Visual C++ compiler.
-        (*it).~ValueType();
+        RefCounter<ValueTraits, StorageTraits>::deref(*it.m_impl);
         m_impl.remove(it.m_impl);
     }
 
index 554bdd87939dde774ca7eb72007956d1b4d8b952..01ac75db39416a5aabe9729db4ff0f00af435eca 100644 (file)
@@ -1,3 +1,11 @@
+2006-05-06  Darin Adler  <darin@apple.com>
+        
+        Suggested by Mitz. Reviewed and landed by Maciej.
+        
+        * dom/Document.cpp: (WebCore::Document::formElementsState): Fixed mistake where the
+        vector has an initial size and instead should have an initial capacity. Harmless in
+        a way, but hurts performance.
+        
 2006-05-07  David Hyatt  <hyatt@apple.com>
 
         Fix for bugzilla bug 8060.
index ceb563a6d179f93f3fbe992eeb85e0d2c5a6d469..1e90c1602b5520e66e8337489bc39ff2cb20ea27 100644 (file)
@@ -3078,7 +3078,8 @@ void Document::finishedParsing()
 
 Vector<String> Document::formElementsState() const
 {
-    Vector<String> stateVector(m_formElementsWithState.size() * 3);
+    Vector<String> stateVector;
+    stateVector.reserveCapacity(m_formElementsWithState.size() * 3);
     typedef HashSet<HTMLGenericFormElement*>::const_iterator Iterator;
     Iterator end = m_formElementsWithState.end();
     for (Iterator it = m_formElementsWithState.begin(); it != end; ++it) {