I'm a newbie at Intel TBB. I'm using concurrent_vector and concurrent_hash_map. I haven't allocate anything using new, so may be there is no memory leak. But I'm getting bad allocation exception. I'm using 32 bit Linux Mint 14 on VMWare workstation which has 3GB of memory. How can I debug is my program leaking memory or it's just the program can't allocate enough memory?

Hi,

I've tried to compile and run this code with tbb 4.1:

http://software.intel.com/sites/products/documentation/doclib/tbb_sa/help/reference/flow_graph/message_flow_graph_example.htm

But found some errors, the changes I did to make it work was to replace:

broadcast_node<int> input;

for

broadcast_node<int> input(g);

and 

make_edge( squarer, std::get<0>( join.inputs() ) );
make_edge( cuber, std::get<1>( join.inputs() ) );

for:

make_edge( squarer, std::get<0>( join.input_ports() ) );
make_edge( cuber, std::get<1>( join.input_ports() ) );

With that I could compile with tbb 4.1 

Regards,

I'm evaluating the commercial version of TBB with Intel Composer XE 2013 on Mac OS X 10.8.3.

My application is built with clang and needs to link with libc++.  When I also link in TBB (debug or release dylib) the application crashes whenever it tries to destruct a std::runtime_error exception that it previously constructed (doesn't need to throw it).

The crash occurs because the runtime_error destructor in libstdc++ is incorrectly being executed instead of the one in libc++ that my application linked with.

Please note that this is not an ABI incompatibility problem due to using libc++ and libstdc++ in the same process.  I'm not throwing the exception (or passing any other library type) across module boundaries.

The libtbb that is bundled with Composer XE 2013 appears to be built with gcc and depends on libstdc++.  The problem appears to be that the dynamic linker loads TBB and hence libstdc++ but then resolves the std::runtime_error destructor from libstdc++ instead of the one in libc++.  Since the runtime_error object was constructed using libc++ and then attempts to destruct using libstdc++, it's not surprising that a crash occurs since the implementations are different.

I can only reproduce the problem with std::runtime_error.  Destructing other exceptions (including ones derived from runtime_error) work fine.  In addition, I can only reproduce the problem when linking TBB.  I tried to create my own shared library that mimics what TBB is doing (and depends on libstdc++) but that worked fine.

Here is a sample program that reproduces the problem:

#include <stdexcept>
#include <iostream>
int main()
{
 {
 std::runtime_error rt("hi");
 std::cout << rt.what() << std::endl;
 }
 // Crash at end of scope when rt destructs
 return 0;
}

Build it like this:

$ clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

TBB=/opt/intel/composer_xe_2013.1.119/tbb/lib/libtbb.dylib
clang++ -stdlib=libc++ myprog.cpp $TBB -o myprog
./myprog

This is the output:

hi
myprog(2226) malloc: *** error for object 0x7feb694039ec: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6 ./myprog

If you run under a debugger you'll see the following stack trace:

0 __kill 0x7fff8754bd46 
1 abort 0x7fff87472df0 
2 free 0x7fff874469b9 
3 std::runtime_error::~runtime_error 0x7fff8d425526 
4 main 0x1000011b7

The address of the runtime_error destructor matches that of libstdc++ instead of the one in libc++.

One obvious solution would be to use a version of TBB that depends on libc++ instead of libstdc++.  Is there a commercial version of TBB available built with libc++?

I'd appreciate any advice or workarounds.