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*));
#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::deallocate (this=0x7fffffffdb40, p=0x7fffe6d79100) at /usr/include/tbb/scalable_allocator.h:146
#5 0x0000000000423f0c in tbb::concurrent_vector >::internal_free_segments (this=0x7fffffffdb40, table=0x7ffff7fb3c00, k=9, first_block=1)
#6 0x0000000000421348 in tbb::concurrent_vector >::~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