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)
commit2e8c479b42c25bcd1fc29f7258225f06a4207323
treea5adca8d3bc084da9dce5d02dcc521100da08e3a
parent0881a5410af8739afe2bb2a3c70be296d633c0e1
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.

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