tbb scalable_malloc spinning in privatizePublicFreeList()

[Customer__Intel6]

Hi,

I am using tbb40_278oss (4.0 update 2) on a 64 bit Scientific Linux 6.1 platform. I have been using the tbb allocator library by setting the LD_PRELOAD override to the proxy library. One of my applications occasionaly (it has so far happened twice over the past 5 months) spins in privatizePublicFreeList(). I have given a stack trace below.

Thread 9 (Thread 9645):

#0 0x00007fa5f33a66d3 in rml::internal::Block::privatizePublicFreeList() () from /tbb40_278oss/lib/SciLi6/libtbbmalloc.so.2

#1 0x00007fa5f33a738f in rml::internal::Bin::getPublicFreeListBlock() () from /tbb40_278oss/lib/SciLi6/libtbbmalloc.so.2

#2 0x00007fa5f33a86c9 in rml::internal::internalPoolMalloc(rml::MemoryPool*, unsigned long) ()

from /tbb40_278oss/lib/SciLi6/libtbbmalloc.so.2

#3 0x00007fa5f33a8d36 in scalable_malloc () from /tbb40_278oss/lib/SciLi6/libtbbmalloc.so.2

#4 0x00007fa5f35ed58a in tbb::internal::allocate_via_handler_v3(unsigned long) () from /tbb40_278oss/lib/SciLi6/libtbb.so.2

#5 0x00007fa5f28bf6b2 in allocate (this=0x7fa5f3333a58, op_insert=true, key=@0x7fa5ecfa7280, result=0x7fa5ecfa7260, write=true, t=0x0)

at /prod/tbb/include/tbb/internal/../tbb_allocator.h:106

#6 operator new (this=0x7fa5f3333a58, op_insert=true, key=@0x7fa5ecfa7280, result=0x7fa5ecfa7260, write=true, t=0x0)

at /prod/tbb/include/tbb/concurrent_hash_map.h:593

#7 tbb::interface5::concurrent_hash_map<:ACE_EVENT_HANDLER>, tbb::tbb_allocator<:PAIR><:ACE_EVENT_HANDLER> > >::lookup (this=0x7fa5f3333a58,

op_insert=true, key=@0x7fa5ecfa7280, result=0x7fa5ecfa7260, write=true, t=0x0)

at /prod/tbb/include/tbb/concurrent_hash_map.h:977

#8 0x00007fa5f28bf81e in insert (this=0x7fa5f3333a00, eh=0x7fa5e5263dd8, mask=, timeout=)

at /prod/tbb/include/tbb/concurrent_hash_map.h:856

...
...

Here is the disassembly from where thread 9 was:

0x00007fa5f33a66c8 <+104>: mov %edx,%esi
0x00007fa5f33a66ca <+106>: mov %rax,%rdi
0x00007fa5f33a66cd <+109>: sub $0x1,%edx
0x00007fa5f33a66d0 <+112>: mov (%rax),%rax
=> 0x00007fa5f33a66d3 <+115>: mov %rax,%rcx
0x00007fa5f33a66d6 <+118>: or $0x1,%rcx
0x00007fa5f33a66da <+122>: cmp $0x1,%rcx
0x00007fa5f33a66de <+126>: jne 0x7fa5f33a66c8 <_ZN3rml8internal5Block23privatizePublicFreeListEv+104>

Address 0x00007fa5f33a66d3 corresponds to line 1161 of tbbmalloc/frontend.cpp:

tbbmalloc/frontend.cpp
1125 void Block::privatizePublicFreeList()
1126 {
1127 FreeObject *temp, *localPublicFreeList;
...
1151 if( !isNotForUse(temp) ) { // return/getPartialBlock could set it to UNUSABLE
1152 MALLOC_ASSERT( allocatedCount <= (blockSize-sizeof(Block))/objectSize, ASSERT_TEXT );
1153 /* other threads did not change the counter freeing our blocks */
1154 allocatedCount--;
1155 while( isSolidPtr(temp->next) ){ // the list will end with either NULL or UNUSABLE
1156 temp = temp->next;
1157 allocatedCount--;
1158 }
1159 MALLOC_ASSERT( allocatedCount < (blockSize-sizeof(Block))/objectSize, ASSERT_TEXT );
1160 /* merge with local freeList */
1161 temp->next = freeList;
1162 freeList = localPublicFreeList;
1163 STAT_increment(owner, getIndex(objectSize), allocPrivatized);
1164 }
1165 }

Register %rax points to next pointer in the freelist and it is circular. Is there some boundary error case?

struct FreeObject {
FreeObject *next;
};

I am using valgrind to check my applicaton for memory corruption. The system was not under memory pressure (300MB real memory free out of 16GB and 0 swap usage). Have you seen this issue before? Would upgrading to the latest TBB release help?

Thanks,
--Kannan.

[Vladimir_P_1234567890]

Actual topic - https://software.intel.com/en-us/forums/topic/520693