I'm having a rather strange issue with sometimes difficult to reproduce crashes. I make use of tbb::concurrent_vector and make one parallel_for call. The rest of the accesses are done serially. I've tried it with both scalable and cache aligned allocators with similar results.
I'm using tbb version 3.0+r147 as available in debian/ubuntu releases.
Please see attached backtrace bellow:
0x00007ffff743996d in rml::internal::getBackRef (backRefIdx=...) at ../../src/tbbmalloc/backref.cpp:155 155 + sizeof(BackRefBlock)+backRefIdx.getOffset()*sizeof(void*)); (gdb) bt #0 0x00007ffff743996d in rml::internal::getBackRef (backRefIdx=...) at ../../src/tbbmalloc/backref.cpp:155 #1 0x00007ffff7437fd0 in isLargeObject (object=0x7fffe6d79100) at ../../src/tbbmalloc/frontend.cpp:1577 #2 rml::internal::isLargeObject (object=0x7fffe6d79100) at ../../src/tbbmalloc/frontend.cpp:1570 #3 0x00007ffff7438073 in rml::internal::internalFree (object=0x7fffe6d79100) at ../../src/tbbmalloc/frontend.cpp:1724 #4 0x0000000000427242 in tbb::scalable_allocator<:GRIB2::MESSAGE>::deallocate (this=0x7fffffffdb40, p=0x7fffe6d79100) at /usr/include/tbb/scalable_allocator.h:146 #5 0x0000000000423f0c in tbb::concurrent_vector<:GRIB2::MESSAGE> >::internal_free_segments (this=0x7fffffffdb40, table=0x7ffff7fb3c00, k=9, first_block=1) at /usr/include/tbb/concurrent_vector.h:927 #6 0x0000000000421348 in tbb::concurrent_vector<:GRIB2::MESSAGE> >::~concurrent_vector (this=0x7fffffffdb40, __in_chrg=) at /usr/include/tbb/concurrent_vector.h:823 #7 0x000000000041f880 in meteor::grib2::grib2::~grib2 (this=0x7fffffffdb40, __in_chrg=) at ../../lib/meteor/include/meteor/grib2/grib2.hpp:45 #8 0x0000000000412918 in main (argc=7, argv=0x7fffffffe048) at main.cpp:224