Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
2421 Discussions

tbb scalable_malloc spinning in privatizePublicFreeList()



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/

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

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

from /tbb40_278oss/lib/SciLi6/

#3 0x00007fa5f33a8d36 in scalable_malloc () from /tbb40_278oss/lib/SciLi6/

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

#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:

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?


0 Kudos
1 Reply