tbb scalable_malloc spinning in privatizePublicFreeList()

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/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, tbb::tbb_allocator > >::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:

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

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
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
temp = temp->next;
1158 }
allocatedCount < (blockSize-sizeof(Block))/objectSize, ASSERT_TEXT );
1160 /* merge with local
freeList */
1161 temp->next = freeList;
1162 freeList =
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?


2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Leave a Comment

Please sign in to add a comment. Not a member? Join today