access violation with concurrent_vector::push_back

access violation with concurrent_vector::push_back

I'm getting an access violation out of cache_aligned_allocator::allocate() when I call push_back() on an empty concurrent_vector. This seems to happen regardless of the value_type of the concurrent_vector. Any ideas? I'm probably just missing something silly...

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

Quoting - kfriddile

poop.exe!tbb::internal::__TBB_InitOnce::lock() + 0x11 bytes
poop.exe!tbb::internal::DoOneTimeInitializations() + 0x21 bytes
poop.exe!tbb::internal::initialize_cache_aligned_allocator() + 0xb9 bytes
poop.exe!tbb::internal::NFS_Allocate() + 0xcf bytes
> poop.exe!tbb::cache_aligned_allocator::allocate(unsigned int n=2, const void * hint=0x00000000) Line 94 + 0xf bytes C++

Thanks. So, it is a bug of the TBB initialization code which affects containers indirectly through the cache aligned allocator. And it seems we already fixed the bug, please check the latest [development] release.
Also, you can try to workaround the issue for your current version of TBB by using another allocator or initializing TBB scheduler firstly.

Quoting - kfriddile
I'm getting an access violation out of cache_aligned_allocator::allocate() when I call push_back() on an empty concurrent_vector. This seems to happen regardless of the value_type of the concurrent_vector. Any ideas? I'm probably just missing something silly...

Can you give us a stack backtrace, versions, and any other information on when and how do you use the concurrent_vector?

Quoting - Anton Malakhov (Intel)

Can you give us a stack backtrace, versions, and any other information on when and how do you use the concurrent_vector?

Compiler: Visual Studio 9.0.30729.1 SP
OS: Vista Ultimate x64
TBB version: 22_20090809oss compiled as static libs

The concurrent_vector is a private member of a class derived from an abstract base. The push_back occurs in an override of one of the base class's public pure virtual methods. The failing push_back is the first operation performed on the concurrent_vector after it is default-constructed. The element type of the concurrent_vector doesn't seem to matter either (it happens with int). Also, the TBB scheduler has not been initialized (I understand it isn't necessary to do so when just using the containers). Here is the call stack:

ntdll.dll!7796dbba()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7796dad6()
messenger_test_deferredPublisher.exe!tbb::internal::__TBB_InitOnce::lock() + 0x11 bytes
messenger_test_deferredPublisher.exe!tbb::internal::DoOneTimeInitializations() + 0x21 bytes
messenger_test_deferredPublisher.exe!tbb::internal::initialize_cache_aligned_allocator() + 0xb9 bytes
messenger_test_deferredPublisher.exe!tbb::internal::NFS_Allocate() + 0xcf bytes
> messenger_test_deferredPublisher.exe!tbb::cache_aligned_allocator::allocate(unsigned int n=2, const void * hint=0x00000000) Line 94 + 0xf bytes C++
messenger_test_deferredPublisher.exe!tbb::concurrent_vector >::internal_allocator(tbb::internal::concurrent_vector_base_v3 & vb={...}, unsigned int k=2) Line 823 C++
messenger_test_deferredPublisher.exe!tbb::internal::concurrent_vector_base_v3::helper::allocate_segment() + 0x29 bytes
messenger_test_deferredPublisher.exe!tbb::internal::concurrent_vector_base_v3::helper::enable_segment() + 0xb9 bytes
messenger_test_deferredPublisher.exe!tbb::internal::concurrent_vector_base_v3::helper::acquire_segment() + 0x55 bytes
messenger_test_deferredPublisher.exe!tbb::internal::concurrent_vector_base_v3::internal_push_back() + 0xb0 bytes
messenger_test_deferredPublisher.exe!tbb::concurrent_vector >::push_back(const rs::DeferredPublisher::HandlerGroup & item={...}) Line 649 + 0x11 bytes C++
messenger_test_deferredPublisher.exe!rs::DeferredPublisher::Publish(const rs::MessageIdentifier & id={...}, boost::shared_ptr message={...}) Line 21 + 0x6f bytes C++
messenger_test_deferredPublisher.exe!DeferredPublisher_Test::DeferredPublisher_Test_CheckPublishNoHandlers::test_method() Line 49 + 0x78 bytes C++
messenger_test_deferredPublisher.exe!DeferredPublisher_Test::DeferredPublisher_Test_CheckPublishNoHandlers_invoker() Line 46 + 0x51 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::invoker::invoke(void (void)* & f=0x00da9f30) Line 56 + 0x21 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::callback0_impl_t::invoke() Line 89 + 0x2f bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::callback0::operator()() Line 118 + 0x25 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::`anonymous namespace'::zero_return_wrapper_t >::operator()() Line 41 + 0x17 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::invoker::invoke > >(boost::unit_test::`anonymous-namespace'::zero_return_wrapper_t > & f={...}) Line 42 + 0xf bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::callback0_impl_t > >::invoke() Line 89 + 0x1d bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::callback0::operator()() Line 118 + 0x21 bytes C++
messenger_test_deferredPublisher.exe!boost::detail::do_invoke,boost::unit_test::callback0 >(const boost::scoped_ptr & tr={...}, const boost::unit_test::callback0 & F={...}) Line 244 + 0x36 bytes C++
messenger_test_deferredPublisher.exe!boost::execution_monitor::catch_signals(const boost::unit_test::callback0 & F={...}) Line 1113 + 0x10 bytes C++
messenger_test_deferredPublisher.exe!boost::execution_monitor::execute(const boost::unit_test::callback0 & F={...}) Line 1167 + 0xc bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::unit_test_monitor_t::execute_and_translate(const boost::unit_test::test_case & tc={...}) Line 69 + 0x39 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::framework_impl::visit(const boost::unit_test::test_case & tc={...}) Line 155 + 0xf bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(const boost::unit_test::test_case & tc={...}, boost::unit_test::test_tree_visitor & V={...}) Line 194 C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(unsigned long id=65539, boost::unit_test::test_tree_visitor & V={...}) Line 232 + 0x16 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(const boost::unit_test::test_suite & suite={...}, boost::unit_test::test_tree_visitor & V={...}) Line 207 + 0xd bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(unsigned long id=2, boost::unit_test::test_tree_visitor & V={...}) Line 234 + 0x16 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(const boost::unit_test::test_suite & suite={...}, boost::unit_test::test_tree_visitor & V={...}) Line 207 + 0xd bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::traverse_test_tree(unsigned long id=1, boost::unit_test::test_tree_visitor & V={...}) Line 234 + 0x16 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::framework::run(unsigned long id=1, bool continue_test=true) Line 441 + 0xf bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::unit_test_main(boost::unit_test::test_suite * (int, char * *)* init_func=0x00da1d7f, int argc=1, char * * argv=0x00d352d0) Line 185 + 0x9 bytes C++
messenger_test_deferredPublisher.exe!main(int argc=1, char * * argv=0x00d352d0) Line 237 + 0x11 bytes C++
messenger_test_deferredPublisher.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
messenger_test_deferredPublisher.exe!mainCRTStartup() Line 403 C
kernel32.dll!7607e3f3()
ntdll.dll!779acfed()
ntdll.dll!779ad1ff()

Quoting - Anton Malakhov (Intel)

Can you give us a stack backtrace, versions, and any other information on when and how do you use the concurrent_vector?

Here's a simpler example that exhibits the same issue:

#include

int main()
{
tbb::concurrent_vector foo;

foo.push_back( 1 ); // access violation here

return 0;
}

ntdll.dll!7796dbba()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7796dad6()
poop.exe!tbb::internal::__TBB_InitOnce::lock() + 0x11 bytes
poop.exe!tbb::internal::DoOneTimeInitializations() + 0x21 bytes
poop.exe!tbb::internal::initialize_cache_aligned_allocator() + 0xb9 bytes
poop.exe!tbb::internal::NFS_Allocate() + 0xcf bytes
> poop.exe!tbb::cache_aligned_allocator::allocate(unsigned int n=2, const void * hint=0x00000000) Line 94 + 0xf bytes C++
poop.exe!tbb::concurrent_vector >::internal_allocator(tbb::internal::concurrent_vector_base_v3 & vb={...}, unsigned int k=2) Line 823 C++
poop.exe!tbb::internal::concurrent_vector_base_v3::helper::allocate_segment() + 0x29 bytes
poop.exe!tbb::internal::concurrent_vector_base_v3::helper::enable_segment() + 0xb9 bytes
poop.exe!tbb::internal::concurrent_vector_base_v3::helper::acquire_segment() + 0x55 bytes
poop.exe!tbb::internal::concurrent_vector_base_v3::internal_push_back() + 0xb0 bytes
poop.exe!tbb::concurrent_vector >::push_back(const int & item=1) Line 649 + 0x11 bytes C++
poop.exe!main() Line 9 C++
poop.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
poop.exe!mainCRTStartup() Line 403 C
kernel32.dll!7607e3f3()
ntdll.dll!779acfed()
ntdll.dll!779ad1ff()

Quoting - Anton Malakhov (Intel)

Thanks. So, it is a bug of the TBB initialization code which affects containers indirectly through the cache aligned allocator. And it seems we already fixed the bug, please check the latest [development] release.
Also, you can try to workaround the issue for your current version of TBB by using another allocator or initializing TBB scheduler firstly.

Thanks. I can confirm the latest development release fixes the issue.

Leave a Comment

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