Assert while inserting item in concurrent_hash_map

[Harsh_Gupta]

Hi,

We've two threads, and both are trying to insert items in concurrent_hash_map using bool insert( accessor& result, const Key& key ) function.

While inserting an item from one of the threads, we encountered this assert __TBB_ASSERT( &get_segment(h)==&s, "hash function changed?" ) in function grow_segment( segment_mutex_t::scoped_lock& segment_lock, segment& s ).

After investigating, we found that tbb is trying to grow the segment in which the current item has to be inserted. While growing the segment and moving data from oldarray to new allocated array, it encountered an item in oldarray that actually shouldnt belong to this particular segment, according to the hashkey generated using HashCompare func. Our hash key function just returns the product of the item (an integer) with a primary number (10631).

Harsh Gupta, Sharad Sonker
Adobe Systems

[RafSchietekat]

As always, what version?

[Anton_M_Intel]

Since the assertion is triggered, it is definitely because of either hash function or key (item.first) changed (explicitly or via memory corruption). They must not be changed, otherwise such an item can be lost from the table.

It also seems that you use TBB < 2.2, however, the latest version of TBB is 3.0 U2 and it has a different implementation of concurrent_hash_map which performs better.
If you still have this problem unsolved, please send me a reproducer.

[Harsh_Gupta]

1) Hash function is certainly not changed. We've only one hash function for both threads.
2) Key is not changed explicitly anywhere, and the key for which exception is coming is also a valid key. I don't know how that key has been pushed into wrong segment.
3) We are using 2.1.2009.415 build.
4) We are only using insert, erase and find functions of concurrent_hash_map.

Any ideas?

Harsh Gupta

[Anton_M_Intel]

I have no more ideas. It seems it is the last tbb release with old implementation that should be quite mature. However, it could make sense to try any other version. And please try create a reproducer.
I'm on vacation for the next two weeks anyway.

[ARCH_R_Intel]

If you can come up with a small example that reproduces the problem, I'm sure we can find someone to look at it even if Anton is on vacation.

I appreciate that it's sometimes tough to come up with small examples.