- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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<:DEFERREDPUBLISHER::HANDLERGROUP>::allocate(unsigned int n=2, const void * hint=0x00000000) Line 94 + 0xf bytes C++
messenger_test_deferredPublisher.exe!tbb::concurrent_vector<:DEFERREDPUBLISHER::HANDLERGROUP> >::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<:DEFERREDPUBLISHER::HANDLERGROUP> >::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> 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<:UNIT_TEST::UT_DETAIL::UNUSED>::invoke(void (void)* & f=0x00da9f30) Line 56 + 0x21 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::callback0_impl_t<:UNIT_TEST::UT_DETAIL::UNUSED>::invoke() Line 89 + 0x2f bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::callback0<:UNIT_TEST::UT_DETAIL::UNUSED>::operator()() Line 118 + 0x25 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<:UNIT_TEST::CALLBACK0><:UNIT_TEST::UT_DETAIL::UNUSED> >::operator()() Line 41 + 0x17 bytes C++
messenger_test_deferredPublisher.exe!boost::unit_test::ut_detail::invoker::invoke<:UNIT_TEST::> > >(boost::unit_test::`anonymous-namespace'::zero_return_wrapper_t<:UNIT_TEST::CALLBACK0><:UNIT_TEST::UT_DETAIL::UNUSED> > & 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<:SCOPED_PTR><:DETAIL::TRANSLATE_EXCEPTION_BASE>,boost::unit_test::callback0 >(const boost::scoped_ptr<:DETAIL::TRANSLATE_EXCEPTION_BASE> & 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()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page