Bug 108435 - HashSet<>::find(0) hits an assertion in debug and returns a bogus iterator
Summary: HashSet<>::find(0) hits an assertion in debug and returns a bogus iterator
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords:
Depends on:
Blocks: 108380
  Show dependency treegraph
 
Reported: 2013-01-30 23:40 PST by Ryosuke Niwa
Modified: 2013-01-31 15:00 PST (History)
8 users (show)

See Also:


Attachments
Fixes the bug (4.27 KB, patch)
2013-01-31 14:37 PST, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2013-01-30 23:40:09 PST
Add the following test case to HashSet.cpp in WTF tests:

TEST(WTF, HashSetFindZero)
{
    HashSet<uint64_t> testSet;

    // Initial capacity is null.
    ASSERT_EQ(0, testSet.capacity());
    testSet.add(static_cast<uint64_t>(123));
    testSet.add(static_cast<uint64_t>(456));
    ASSERT_TRUE(testSet.find(static_cast<uint64_t>(0)) == testSet.end());
}

You'll hit an assertion in

    template<typename Key, typename Value, typename Extractor, typename HashFunctions, typename Traits, typename KeyTraits>
    template<typename HashTranslator, typename T>
    void HashTable<Key, Value, Extractor, HashFunctions, Traits, KeyTraits>::checkKey(const T& key)
    {
        if (!HashFunctions::safeToCompareToEmptyOrDeleted)
            return;
        ASSERT(!HashTranslator::equal(KeyTraits::emptyValue(), key));

This results in HashSet::find returning a bogus iterator and HashSet::remove deleting an unrelated item, resulting in a really bad consistent state where size can be a bogus value like -1.
Comment 1 Ryosuke Niwa 2013-01-31 14:37:26 PST
Created attachment 185869 [details]
Fixes the bug
Comment 2 Ryosuke Niwa 2013-01-31 14:49:26 PST
Comment on attachment 185869 [details]
Fixes the bug

Sam says we shouldn't do this.
Comment 3 Ryosuke Niwa 2013-01-31 14:49:54 PST
I'll fix the internal code instead.
Comment 4 Benjamin Poulain 2013-01-31 15:00:02 PST
This is by design, but you can just change the HashTrait to support the value 0.