Changeset 14221 in webkit for trunk/JavaScriptCore

Timestamp:

May 7, 2006, 9:59:28 PM (19 years ago)

Author:

mjs

Message:

JavaScriptCore:

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.

Location:

trunk/JavaScriptCore

Files:

• ChangeLog (modified) (1 diff)
• kxmlcore/HashMap.h (modified) (1 diff)
• kxmlcore/HashSet.h (modified) (1 diff)

trunk/JavaScriptCore/ChangeLog

@@ +1 @@
+2006-05-06  Darin Adler  <[email protected]>
+
+        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  <[email protected]>
 

trunk/JavaScriptCore/kxmlcore/HashMap.h

@@ -289 +289 @@
         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);
     }

trunk/JavaScriptCore/kxmlcore/HashSet.h

@@ -275 +275 @@
         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);
     }