Changeset 27487 in webkit


Ignore:
Timestamp:
Nov 6, 2007 1:37:40 PM (16 years ago)
Author:
Darin Adler
Message:

Reviewed by Maciej.

There was a mistake in the algorithm used to find an empty slot in the property
map entries vector; when we were putting in a new property value and not overwriting
an existing deleted sentinel, we would enlarge the entries vector, but would not
overwrite the stale data that's in the new part. It was easy to pin this down by
turning on property map consistency checks -- I never would have landed with this
bug if I had run the regression tests once with consistency checks on!

  • kjs/property_map.cpp: (KJS::PropertyMap::put): Changed logic for the case where foundDeletedElement is false to always use the item at the end of the entries vector. Also allowed me to merge with the logic for the "no deleted sentinels at all" case.
Location:
trunk/JavaScriptCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/JavaScriptCore/ChangeLog

    r27484 r27487  
     12007-11-06  Darin Adler  <darin@apple.com>
     2
     3        Reviewed by Maciej.
     4
     5        - http://bugs.webkit.org/show_bug.cgi?id=15846
     6          REGRESSION (r27387): Memory corruption when running fast/js/kde/delete.html
     7
     8        There was a mistake in the algorithm used to find an empty slot in the property
     9        map entries vector; when we were putting in a new property value and not overwriting
     10        an existing deleted sentinel, we would enlarge the entries vector, but would not
     11        overwrite the stale data that's in the new part. It was easy to pin this down by
     12        turning on property map consistency checks -- I never would have landed with this
     13        bug if I had run the regression tests once with consistency checks on!
     14
     15        * kjs/property_map.cpp: (KJS::PropertyMap::put): Changed logic for the case where
     16        foundDeletedElement is false to always use the item at the end of the entries vector.
     17        Also allowed me to merge with the logic for the "no deleted sentinels at all" case.
     18
    1192007-11-06  Oliver Hunt  <oliver@apple.com>
    220
  • trunk/JavaScriptCore/kjs/property_map.cpp

    r27387 r27487  
    414414
    415415    // Figure out which entry to use.
    416     unsigned entryIndex;
    417     if (!m_u.table->deletedSentinelCount)
    418         entryIndex = m_u.table->keyCount + 2;
    419     else {
    420         if (foundDeletedElement) {
    421             i = deletedElementIndex;
    422             --m_u.table->deletedSentinelCount;
    423         }
    424         for (entryIndex = m_u.table->keyCount + m_u.table->deletedSentinelCount + 2;
    425                 m_u.table->entries()[entryIndex - 1].key; --entryIndex)
     416    unsigned entryIndex = m_u.table->keyCount + m_u.table->deletedSentinelCount + 2;
     417    if (foundDeletedElement) {
     418        i = deletedElementIndex;
     419        --m_u.table->deletedSentinelCount;
     420
     421        // Since we're not making the table bigger, we can't use the entry one past
     422        // the end that we were planning on using, so search backwards for the empty
     423        // slot that we can use. We know it will be there because we did at least one
     424        // deletion in the past that left an entry empty.
     425        while (m_u.table->entries()[--entryIndex].key)
    426426            ;
    427427    }
Note: See TracChangeset for help on using the changeset viewer.